From nobody Wed Apr 14 09:00:41 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBA83A14DB for ; Wed, 14 Apr 2021 09:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=NqASkRNU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H3X8YbrX 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 AczzcXT5eG6a for ; Wed, 14 Apr 2021 09:00:35 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E0F3A14D9 for ; Wed, 14 Apr 2021 09:00:35 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2F4265C00F9; Wed, 14 Apr 2021 12:00:31 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 14 Apr 2021 12:00:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=L2Gz oBUSNL8FMzsS3oY5mdp2hVMVlw7VS74dYl9rNYQ=; b=NqASkRNUDrj9YTkwjxMr SPT9NkHtyVjAE+bRAqeVVptRGVZom5K98MZYfnDN3Mxyg3pUy+gqcTihrUoobjcv AeGOunk1k47JYdq6Fxd3XQndl5ryVeu5qof2ptTPQ4kNPWT4x/Z6H3bAq9aFkMCA bdeb472XYGnbhoHUHl3EMkCYrOwanxp0tMpYpArnaCYtuFoPCBSlJ0dPZztgvzVA HxEinaqQYLJ43s0WircB/QLduO/Rsfl2djoRtcdmAeFU5F/Fin4Qb7OOELy/PS6g WNqaF5cGN4xmu5+dN46F7jqntgufOJuC8rpEi9Cpg1XaitU3C2JyuCdbsRA841dx 7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=L2GzoB USNL8FMzsS3oY5mdp2hVMVlw7VS74dYl9rNYQ=; b=H3X8YbrXjJrGi2sa6njtt0 9D5XPTBhvJYnjw4y5moVhoeJWtcpTa9RNOYgCB1NnlGriv2rDBM7AhD4Uv2AjO/5 FXKiFb2coIj8xtjF/BUu7UJYUR7Owj24myNkVisAJbUa/u8hXS4VUIK4aDPuafcN VWWhv9wpx0v3Ta5Z7mFRR5n7flk8s0bbm/zs7ATZl563qWtgCBocuXA95l7laD2b 0eD0xu4C6bKq94/VMR9wDPxzVcfkLpCgEfTMoW76d0Kg41TnSx4IWUbhworyZEGQ L+XTSTuy/qwjlgCciGI9jsaHDTAs4Bb86jy5yOuZf2tlyKxnDIr65Mf6S48CVqkg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeluddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepffevfeeigfejveetheehleegteelteevgeeutdfhhefg hfdtjefhvdehhfdtkefgnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 76798260005F; Wed, 14 Apr 2021 12:00:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-378-g5ea5579899-fm-20210412.001-g5ea55798 Mime-Version: 1.0 Message-Id: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> In-Reply-To: References: Date: Thu, 15 Apr 2021 02:00:09 +1000 From: "Bron Gondwana" To: dispatch@ietf.org, "Murray S. Kucherawy" Cc: "Ujjwal Sharma" , "Shane Carr" Content-Type: multipart/alternative; boundary=d18cd176a36a4583b929e67f7c7db54b Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 14 Apr 2021 16:00:40 -0000 --d18cd176a36a4583b929e67f7c7db54b Content-Type: text/plain This was discussed in the DISPATCH meeting at IETF110: https://datatracker.ietf.org/doc/minutes-110-dispatch/ The conclusion of the discussion was: * Kirsty (chair): Sounds like there's general agreement that a working group is what's needed, we will take a final decision on the list and just confirm with Patrick as co-chair before officially dispatching as such. The link to the charter is on list too, please take a look and see if you think a BoF is needed as the next step or a WG can begin right away. So Murray (AD), do you think we have enough to request a working group be charted from the discussion and the proposed charter text quoted below? Thanks, Bron. On Fri, Feb 19, 2021, at 15:20, Bron Gondwana wrote: > I've asked the chairs for space on the next dispatch agenda to talk about dispatch for > > https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ > > The authors have taken on board the idea that we should extract the "obsolete RFC3339" and either remove it entirely, or separate it into a document which does nothing but update RFC3339 with support for a wider range of year values. There will be an updated version of this draft soon. > > The dispatch chairs also asked me for some proposed charter text if we were to spin up a working group for this topic. Here's that text. > > Cheers, > > Bron. > > Serialising Extended Data About Times and Events (SEDATE) > ---- > > RFC3339 defines a format that can reliably express an instant in time, either in UTC or in a local time along with the offset against UTC, however datetime data often has additional context, such as the timezone or calendar system that was in use when that instant was recorded. Particularly when using times for interval, recurrence, or offset calculations, it's necessary to know the context in which the timepoint exists. > > It is valuable to have a serialisation format which retains this context and can reliably round-trip the additional context to systems which understand it, via intermediate systems which only need to know about the instant in time. > > The TC39 working group at ECMA have developed a format which is a good basis for this work. > > It is anticipated that this document would be a companion to RFC3339 rather than a replacement, embedding an un-altered RFC3339 instant along with the contextual data. > > It is also within scope for this group to consider a minor update to RFC3339 to allow larger than 4 digit signed years, to enable representing times further into the past and future. > > Once this work is done it is anticipated that this working group will be short-lived, and once the one or two documents are published the working group will close down. > > Milestones: > * April 2021: Adopt draft describing a serialisation format for extended datetimes. > * July 2021: Submit the serialisation document to the IESG. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d18cd176a36a4583b929e67f7c7db54b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This was discussed in the DISPATCH meeting at IETF110= : htt= ps://datatracker.ietf.org/doc/minutes-110-dispatch/

T= he conclusion of the discussion was:

* Kirsty (chair): Sounds like there's general agr=
eement that a working group is
what's needed, we will take a final decision on the list and just confir=
m with
Patrick as co-chair before officially dispatching as such. The link to t=
he
charter is on list too, please take a look and see if you think a BoF is=
 needed
as the next step or a WG can begin right away.

So Murray = (AD), do you think we have enough to request a working group be charted = from the discussion and the proposed charter text quoted below?

Thanks,

Bron.

On Fri, Feb 19, 2021, at 15:20, Bron Gondwana wrot= e:
I've asked the chairs for space on the next dispatc= h agenda to talk about dispatch for


The authors have taken on board the idea that we should extract the "o= bsolete RFC3339" and either remove it entirely, or separate it into a do= cument which does nothing but update RFC3339 with support for a wider ra= nge of year values.  There will be an updated version of this draft= soon.

The dispatch chairs also asked me for some proposed= charter text if we were to spin up a working group for this topic. = ; Here's that text.

Cheers,

Bron.

Serialising Extended Data Ab= out Times and Events (SEDATE)
----

RFC3339 defines a format that can reliably express an instant in tim= e, either in UTC or in a local time along with the offset against UTC, however dateti= me data often has additional context, such as the timezone or calendar system th= at was in use when that instant was recorded. Particularly when using times for i= nterval, recurrence, or offset calculations, it's necessary to know the context i= n which the timepoint exists.

<= div style=3D"font-family:Arial;">It is valuable to have a serialisation format which retain= s this context and can reliably round-trip the additional context to systems which understand i= t, via intermediate systems which only need to know about the instant in time.<= /span>

The T= C39 working group at ECMA have developed a format which is a good basis = for this work.

It is anticipated that this document would be a companion to RFC3339= rather than a replacement, embedding an un-altered RFC3339 instant along= with the contextual data.

<= /div>
It is also within scope for this group to consider= a minor update to RFC3339 to allow larger than 4 digit signed years, to enable representing times fur= ther into the past and future.
=
Once this work is done it is anticipated that this working= group will be short-lived, and once the one or two documents are publis= hed the working group will close down.
<= /span>
Milestones:
* April 2021: Adopt draft describing a serialisation format for e= xtended datetimes.
* July= 2021: Submit the serialisation document to the IESG.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com



--
&nb= sp; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com

<= /div>

--d18cd176a36a4583b929e67f7c7db54b-- From nobody Wed Apr 14 10:37:58 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60F13A18D9 for ; Wed, 14 Apr 2021 10:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 313TWuKcnhq6 for ; Wed, 14 Apr 2021 10:37:52 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E0A3A18D5 for ; Wed, 14 Apr 2021 10:37:52 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lWjSX-000GuJ-54; Wed, 14 Apr 2021 13:37:49 -0400 Date: Wed, 14 Apr 2021 13:37:43 -0400 From: John C Klensin To: Bron Gondwana cc: dispatch@ietf.org, "Murray S. Kucherawy" , Ujjwal Sharma , Shane Carr Message-ID: <0C8FFDA77AF247414013590D@PSB> In-Reply-To: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.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] Proposed charter for extended date format 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, 14 Apr 2021 17:37:57 -0000 Bron, Without expressing a point of view on the merits of this particular proposal described in this I-D or even about whether a WG is created, I note with some concern the current discussion on the ART list abut Date formats and what I gather have been some issues with intervals and future times in calendaring (in spite of the I-D excluding intervals from its scope). I also note that the I-D does not appear to show awareness of changes in ISO 8601 in 2019 (including the addition of ISO 8601-2:2019). While it was probably appropriate when RFC 3339 was written 20 years ago, the interconnections between IETF work (and formats) and formats emerging from, or being utilized in, work done elsewhere that it seems to me that developing IETF-specific extension or profiles requires much stronger justification than I see in either the proposed charter or in draft-ryzokuken-datetime-extended-01. If anything, a new document --especially if it proposes to replace 3339-- should be much more tightly and explicitly bound to ISO 8601 (and the current version of that spec) than 3339 was. In the same context and as I have tried to say around the time of the Dispatch meeting discussion, many specifications developed in ECMA TCs move into ISO are are adopted into International Standards unchanged. Some don't. It would be, at least IMO, very unfortunate if we adopted a particular syntax that then turned out to be incompatible with a future extension or revision to ISO 8601. Especially if we want to get out ahead of the ISO Standard, one of the responsibilities of the WG should be to work with the IAB to establish a liaison with the relevant ISO TC or SC so that we can formally tell them what we are doing (in conjunction or parallel with ECMA TC 39) and make the case that the relevant standards should evolve in parallel rather than diverging. FWIW, I note that your 19 February note indicates that the authors have decided on some strategy other than replacing 3339 and that a draft reflecting their revised proposal would appear "soon". According to the datatracker, draft-ryzokuken-datetime-extended-01 (2021-01-22) is still current. In addition, I note that the current I-D repeats the phrasing "this document focuses on just one common usage, viz. timestamps for Internet protocol events", copied from 3339. At this point, we know better than to believe in such a restriction (as the discussion about 3339 versus 5322 dates, the CALDAV work, etc., show). The WG should not be allowed to evaluate only the implications for such timestamps as it considering the consequences and possible tradeoffs in its work. I want to stress that I am strongly in favor of work to better define date-time formats in a clear and uniform way in the IETF. If I were not, I would not have taken the time to write this note. However, precisely because of that, I'd like to see the potential WG move forward on the strongest basis -- and the clearest understanding of the scope and direction of the work-- as possible. I think we are close, but the above issues suggest that we are not quite there yet. Two final notes/ asides: * We have two ART ADs. Because the number of WGs in the Area and how they interact affects both of them (and all of the rest of us), is it appropriate for your question to be addressed to Murray alone? * As discussions of the TERM WG (or possible alternatives to it) move forward, it is worth noting that the term "AD" is hurtful and offensive to some people who understand its definition and do not accept its implications. There are many alternate terms for describing positive offsets in the Gregorian calendar that do not have those implications. It is less of a problem (at least from my personal perspective) but starting the range of defined dates at year zero in that calendar can be considered offensive too. best, john --On Thursday, April 15, 2021 02:00 +1000 Bron Gondwana wrote: > This was discussed in the DISPATCH meeting at IETF110: > https://datatracker.ietf.org/doc/minutes-110-dispatch/ > > The conclusion of the discussion was: > > * Kirsty (chair): Sounds like there's general agreement that a > working group is what's needed, we will take a final decision > on the list and just confirm with Patrick as co-chair before > officially dispatching as such. The link to the charter is on > list too, please take a look and see if you think a BoF is > needed as the next step or a WG can begin right away. > > So Murray (AD), do you think we have enough to request a > working group be charted from the discussion and the proposed > charter text quoted below? > > Thanks, > > Bron. > > On Fri, Feb 19, 2021, at 15:20, Bron Gondwana wrote: >> I've asked the chairs for space on the next dispatch agenda >> to talk about dispatch for >> >> https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-ext >> ended/ >> >> The authors have taken on board the idea that we should >> extract the "obsolete RFC3339" and either remove it entirely, >> or separate it into a document which does nothing but update >> RFC3339 with support for a wider range of year values. There >> will be an updated version of this draft soon. >> >> The dispatch chairs also asked me for some proposed charter >> text if we were to spin up a working group for this topic. >> Here's that text. >> >> Cheers, >> >> Bron. >> >> Serialising Extended Data About Times and Events (SEDATE) >> ---- >> >> RFC3339 defines a format that can reliably express an instant >> in time, either in UTC or in a local time along with the >> offset against UTC, however datetime data often has >> additional context, such as the timezone or calendar system >> that was in use when that instant was recorded. Particularly >> when using times for interval, recurrence, or offset >> calculations, it's necessary to know the context in which the >> timepoint exists. >> >> It is valuable to have a serialisation format which retains >> this context and can reliably round-trip the additional >> context to systems which understand it, via intermediate >> systems which only need to know about the instant in time. >> >> The TC39 working group at ECMA have developed a format which >> is a good basis for this work. >> >> It is anticipated that this document would be a companion to >> RFC3339 rather than a replacement, embedding an un-altered >> RFC3339 instant along with the contextual data. >> >> It is also within scope for this group to consider a minor >> update to RFC3339 to allow larger than 4 digit signed years, >> to enable representing times further into the past and future. >> >> Once this work is done it is anticipated that this working >> group will be short-lived, and once the one or two documents >> are published the working group will close down. >> >> Milestones: >> * April 2021: Adopt draft describing a serialisation format >> for extended datetimes. * July 2021: Submit the serialisation >> document to the IESG. >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >> >> > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > From nobody Wed Apr 14 10:42:37 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3983A1903 for ; Wed, 14 Apr 2021 10:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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 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 b968Tbaoz_3k for ; Wed, 14 Apr 2021 10:42:30 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC8D3A1910 for ; Wed, 14 Apr 2021 10:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25835; q=dns/txt; s=iport; t=1618422150; x=1619631750; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ImGkiLPrCU+ZTcudwwpyPIRR06jMvt+8AFJ3twfdcL8=; b=AEpMa5M9LvZf15C1zX4KLBIR+Fwu/tLvX9uKdSAw1MnvAz6oEQrNXlJg HAkGg7N8vd9DfBzHyIl4lMOjONc34bUaJiNzpjWMp0wt9fapwm4RqU4+Y Ga5zeHaWDUYIRks2tv9ayZIc5fwqkZxLjFRaCZek/jvlNggimZqlKaa7I c=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AJAAA6KXdglxbLJq1aGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBQAQBAQELAYEigX9WAScSMY1HiGsDh3uSb4F8BAcBAQEKAwEBHQEKD?= =?us-ascii?q?AQBAYQMRAKBdCY2Bw4CAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFoh?= =?us-ascii?q?VANhkQBAQEDAQEBbAsFCwsYIAcHJx8RBhOCcQGCZiEPrR93gTSBAYNDBAxBR?= =?us-ascii?q?IR3CgaBOQGBUmKES4ZUQ4ILgRMnHIIwLz6CYAEBA4ITgxaCKwSBVBJOdgEDG?= =?us-ascii?q?ygQUAsLC2wfeJNIigeLJJFigxWDP4FGhGKTHAQfg02Ke4VnkEmXJoldknlHA?= =?us-ascii?q?YQBAgQGBQIWgVsKJ4FbMxoIGxU7KgGCPj4SGQ5VjWOIa4VHPwMvOAIGCgEBA?= =?us-ascii?q?wmNDgEB?= IronPort-HdrOrdr: A9a23:swrTNaj48YHzT2B/67GPn4wZpXBQXlgji2hD6mlwRA09T+Wzna mV7Zcm/DXzjyscX2xlpMCYNMC7LU/02JZp7eAqXIuKcxLhvAKTRr1KzYyn+DH4Hj27y+g178 ddWoxzEsf5A1Q/rcuS2mSFOvIhxNXCz6yyn+fZyB5WIj1CUK1r4wdnBgvzKCQfLzVuPpY3GI GR4cBKvVObCBEqR/6mDXoIVfWrnbP2va/hCCR2ZSIP2U2rhTOs5KWSKWn94j4uFxVS3Lwl7W /J1yv+66nLiYDc9jbsk0nO8p9RhNztjuFmOfXJoM0UJjLw4zzYA7hcZw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,223,1613433600"; d="asc'?scan'208,217";a="35044733" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Apr 2021 17:42:25 +0000 Received: from [10.61.144.120] ([10.61.144.120]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 13EHgOut006114 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Apr 2021 17:42:24 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AC14EB44-9ADB-49A8-8A2B-736D1A379A7B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 14 Apr 2021 19:42:23 +0200 In-Reply-To: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> Cc: dispatch@ietf.org, "Murray S. Kucherawy" , Ujjwal Sharma , Shane Carr To: Bron Gondwana References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.120, [10.61.144.120] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 14 Apr 2021 17:42:35 -0000 --Apple-Mail=_AC14EB44-9ADB-49A8-8A2B-736D1A379A7B Content-Type: multipart/alternative; boundary="Apple-Mail=_908576C4-29D0-4F75-B779-118DF8EA4624" --Apple-Mail=_908576C4-29D0-4F75-B779-118DF8EA4624 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just one question: Is it necessary for both the IETF and TC39 to standardize this? Eliot > On 14 Apr 2021, at 18:00, Bron Gondwana = wrote: >=20 > This was discussed in the DISPATCH meeting at IETF110: = https://datatracker.ietf.org/doc/minutes-110-dispatch/ = >=20 > The conclusion of the discussion was: >=20 > * Kirsty (chair): Sounds like there's general agreement that a working = group is > what's needed, we will take a final decision on the list and just = confirm with > Patrick as co-chair before officially dispatching as such. The link to = the > charter is on list too, please take a look and see if you think a BoF = is needed > as the next step or a WG can begin right away. >=20 > So Murray (AD), do you think we have enough to request a working group = be charted from the discussion and the proposed charter text quoted = below? >=20 > Thanks, >=20 > Bron. >=20 > On Fri, Feb 19, 2021, at 15:20, Bron Gondwana wrote: >> I've asked the chairs for space on the next dispatch agenda to talk = about dispatch for >>=20 >> https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ = >>=20 >> The authors have taken on board the idea that we should extract the = "obsolete RFC3339" and either remove it entirely, or separate it into a = document which does nothing but update RFC3339 with support for a wider = range of year values. There will be an updated version of this draft = soon. >>=20 >> The dispatch chairs also asked me for some proposed charter text if = we were to spin up a working group for this topic. Here's that text. >>=20 >> Cheers, >>=20 >> Bron. >>=20 >> Serialising Extended Data About Times and Events (SEDATE) >> ---- >>=20 >> RFC3339 defines a format that can reliably express an instant in = time, either in UTC or in a local time along with the offset against = UTC, however datetime data often has additional context, such as the = timezone or calendar system that was in use when that instant was = recorded. Particularly when using times for interval, recurrence, or = offset calculations, it's necessary to know the context in which the = timepoint exists. >>=20 >> It is valuable to have a serialisation format which retains this = context and can reliably round-trip the additional context to systems = which understand it, via intermediate systems which only need to know = about the instant in time. >>=20 >> The TC39 working group at ECMA have developed a format which is a = good basis for this work. >>=20 >> It is anticipated that this document would be a companion to RFC3339 = rather than a replacement, embedding an un-altered RFC3339 instant along = with the contextual data. >>=20 >> It is also within scope for this group to consider a minor update to = RFC3339 to allow larger than 4 digit signed years, to enable = representing times further into the past and future. >>=20 >> Once this work is done it is anticipated that this working group will = be short-lived, and once the one or two documents are published the = working group will close down. >>=20 >> Milestones: >> * April 2021: Adopt draft describing a serialisation format for = extended datetimes. >> * July 2021: Submit the serialisation document to the IESG. >>=20 >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 >=20 > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_908576C4-29D0-4F75-B779-118DF8EA4624 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = one question:

Is it = necessary for both the IETF and TC39 to standardize = this?

Eliot

On 14 Apr 2021, at 18:00, Bron Gondwana <brong@fastmailteam.com> wrote:

This was discussed in the DISPATCH = meeting at IETF110: https://datatracker.ietf.org/doc/minutes-110-dispatch/

The conclusion of the discussion = was:

* =
Kirsty (chair): Sounds like there's general agreement that a working =
group is
what's needed, we will take a final decision on the list and just =
confirm with
Patrick as co-chair before officially dispatching as such. The link to =
the
charter is on list too, please take a look and see if you think a BoF is =
needed
as the next step or a WG can begin right away.

So Murray (AD), do you think we have enough to = request a working group be charted from the discussion and the proposed = charter text quoted below?

Thanks,

Bron.

On Fri, Feb 19, 2021, at 15:20, Bron Gondwana = wrote:
I've asked the chairs for space on the next dispatch agenda = to talk about dispatch for

https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-exten= ded/

The authors have taken on board the idea that we should = extract the "obsolete RFC3339" and either remove it entirely, or = separate it into a document which does nothing but update RFC3339 with = support for a wider range of year values.  There will be an updated = version of this draft soon.

The dispatch chairs also asked me for some proposed = charter text if we were to spin up a working group for this topic.  = Here's that text.

Cheers,

Bron.

Serialising Extended Data About Times and Events = (SEDATE)
----

RFC3339 = defines a format that can reliably express an instant in time, either in = UTC or in a local time along with the offset against UTC, however = datetime data often has additional context, such as the timezone or = calendar system that was in use when that instant was recorded. = Particularly when using times for interval, recurrence, or offset = calculations, it's necessary to know the context in which the timepoint = exists.

It is = valuable to have a serialisation format which retains this context and = can reliably round-trip the additional context to systems which = understand it, via intermediate systems which only need to know about = the instant in time.

The TC39 = working group at ECMA have developed a format which is a good basis for = this work.

It is = anticipated that this document would be a companion to RFC3339 rather = than a replacement, embedding an un-altered RFC3339 instant along with = the contextual data.

It is = also within scope for this group to consider a minor update to RFC3339 = to allow larger than 4 digit signed years, to enable representing times = further into the past and future.

Once this = work is done it is anticipated that this working group will be = short-lived, and once the one or two documents are published the working = group will close down.

Milestones:
* April = 2021: Adopt draft describing a serialisation format for extended = datetimes.
* July 2021: Submit the serialisation = document to the IESG.

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



--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


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

= --Apple-Mail=_908576C4-29D0-4F75-B779-118DF8EA4624-- --Apple-Mail=_AC14EB44-9ADB-49A8-8A2B-736D1A379A7B 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmB3KX8ACgkQh7ZrRtnS ejM8cggAztROOG0OlDG7wMDSj6FDBwAWeycVvR8f1vMAl2dnm2nofQfg/5H3H6r9 Y4rGxf7jEaYpWbgfgCoAiYqZwgp9cvfJJP+qN+4hnEX1j6o0KEZhfnEqQdOolviY UpbhgTNapE6p5FfzRGxtagiZ6G4tfYjMufrwHwG52JSy3CYmODKFQlSNVebM6pH0 cWnX7Gd7Nkl2NkQMuy2jfgI7FY5BUAuQqZiVYqnEjSK1oIuBO5XZ56fyq/09SVoL GGoj8QpZR9kBOrAT2nqCStjb9mvSszVLu0rsKrsidLqsbecnvLgw8tc1WXxJF9JZ t+2pSaEXljkGsAhVkv6apX7pUxxTDQ== =Uvg0 -----END PGP SIGNATURE----- --Apple-Mail=_AC14EB44-9ADB-49A8-8A2B-736D1A379A7B-- From nobody Wed Apr 14 10:49:01 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FF03A194B; Wed, 14 Apr 2021 10:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3mWo8Fd91Ih; Wed, 14 Apr 2021 10:48:57 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528083A1946; Wed, 14 Apr 2021 10:48:57 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lWjdH-000Gzb-RD; Wed, 14 Apr 2021 13:48:55 -0400 Date: Wed, 14 Apr 2021 13:48:50 -0400 From: John C Klensin To: Eliot Lear , Bron Gondwana cc: Ujjwal Sharma , dispatch@ietf.org, Shane Carr Message-ID: <0E58D894057CC085A71CE062@PSB> In-Reply-To: References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 14 Apr 2021 17:49:00 -0000 --On Wednesday, April 14, 2021 19:42 +0200 Eliot Lear wrote: > Just one question: > > Is it necessary for both the IETF and TC39 to standardize this? Eliot, See the note I just posted but to extract a quick comment for those who are disinclined to read long notes... You might reasonably has said: Is it necessary for both the IETF, ECMA TC39, and, perhaps unless they can be guaranteed to adopt the ECMA proposal, ISO, to standardize this? IMO, good question. john From nobody Wed Apr 14 11:00:37 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6613A19B8 for ; Wed, 14 Apr 2021 11:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=EIUErqlG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B+bY/L0J 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 AgfCmbBLWqp0 for ; Wed, 14 Apr 2021 11:00:31 -0700 (PDT) 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 459333A19B3 for ; Wed, 14 Apr 2021 11:00:31 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 46CD75C0115; Wed, 14 Apr 2021 14:00:29 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 14 Apr 2021 14:00:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=ebH/ nXF0WKdPYdIS2SYvzmSldL+SEKcOH//Mr29qL4A=; b=EIUErqlG0C0dAXsrsMXf Gz+shQfBgX8f2XuaQV3ohTN+v/9YKPeTuMVURKx3AamwLVuDBL/uonZdTAEt+PMm lMBf6y+X/xroBkWGwvjAWrHC4zPeD1I+gRycNVhe49ee+Fr585C2l8nHRoPTvXD/ Eg0vmlic2tBSEkv3TFQVp2t3GUGundWWzifnhi9z7B+xSTICnZyB1vW0WRfs7OdN GBS8ZdrUdmNQnOYTsAEJaqW/I5vFGdxy7uea6B8QuOZTOtp9owZzIs4CBvmmrgTV xxrK+ObIQAW88LgNoOlTllE0VRqcrF2kjjNW1O1B7L/BJt5fe7Slq3sObattyFLq 8w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ebH/nX F0WKdPYdIS2SYvzmSldL+SEKcOH//Mr29qL4A=; b=B+bY/L0JrwpqqexwyYRFqs tLlaqGICtM76o9YhAK+ylA8CmmhDMzyjEiVI4DJpCq4MiqjftA0FHm2s3+wVGP0o nIYiBmQb9n1LHvF3WWChdKd5RuJDyRNtiWASsjwPtpco1Bv5ptxHOT76HVNjLPrz HL9jTAZVJoqnIE/0IHZfQJMJfK3cIdSSDita7iT8Sxiul4RTOkGNVjT5RjFdmF20 +/Gx4rdvNEaMqnWpD8TCCf8b8C6x0KpIMfsP64r2ldEhndAKUKrxjNKJWOHTbnCd AHHn+JEG9hQHRMmVc1X4ArZrPXR3dXLzrAZbduCfdkHWvFSvgvxJINuz+VgZkD0g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeluddguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehr ohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeffveefiefgjeevteehheelgeetleetveeguedthfeh gffhtdejhfdvhefhtdekgfenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshht mhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B6284260005F; Wed, 14 Apr 2021 14:00:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-378-g5ea5579899-fm-20210412.001-g5ea55798 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> Date: Thu, 15 Apr 2021 04:00:06 +1000 From: "Bron Gondwana" To: "Eliot Lear" Cc: dispatch@ietf.org, "Murray S. Kucherawy" , "Ujjwal Sharma" , "Shane Carr" Content-Type: multipart/alternative; boundary=9acd9cd7e6dd49c98e4005836ed68ea6 Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 14 Apr 2021 18:00:36 -0000 --9acd9cd7e6dd49c98e4005836ed68ea6 Content-Type: text/plain I think the idea is that TC39 doesn't want to standardise something DIFFERENT than the rest of the world, so trying to get IETF to go first makes sense. Failing that, TC39 can just do its own thing and hope the rest of the world follows, but that means it doesn't get a change to have as much outside review as the IETF process gives. Bron. On Thu, Apr 15, 2021, at 03:42, Eliot Lear wrote: > Just one question: > > Is it necessary for *both* the IETF and TC39 to standardize this? > > Eliot > >> On 14 Apr 2021, at 18:00, Bron Gondwana wrote: >> >> This was discussed in the DISPATCH meeting at IETF110: https://datatracker.ietf.org/doc/minutes-110-dispatch/ >> >> The conclusion of the discussion was: >> >> * Kirsty (chair): Sounds like there's general agreement that a working group is what's needed, we will take a final decision on the list and just confirm with Patrick as co-chair before officially dispatching as such. The link to the charter is on list too, please take a look and see if you think a BoF is needed as the next step or a WG can begin right away. >> >> So Murray (AD), do you think we have enough to request a working group be charted from the discussion and the proposed charter text quoted below? >> >> Thanks, >> >> Bron. >> >> On Fri, Feb 19, 2021, at 15:20, Bron Gondwana wrote: >>> I've asked the chairs for space on the next dispatch agenda to talk about dispatch for >>> >>> https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ >>> >>> The authors have taken on board the idea that we should extract the "obsolete RFC3339" and either remove it entirely, or separate it into a document which does nothing but update RFC3339 with support for a wider range of year values. There will be an updated version of this draft soon. >>> >>> The dispatch chairs also asked me for some proposed charter text if we were to spin up a working group for this topic. Here's that text. >>> >>> Cheers, >>> >>> Bron. >>> >>> Serialising Extended Data About Times and Events (SEDATE) >>> ---- >>> >>> RFC3339 defines a format that can reliably express an instant in time, either in UTC or in a local time along with the offset against UTC, however datetime data often has additional context, such as the timezone or calendar system that was in use when that instant was recorded. Particularly when using times for interval, recurrence, or offset calculations, it's necessary to know the context in which the timepoint exists. >>> >>> It is valuable to have a serialisation format which retains this context and can reliably round-trip the additional context to systems which understand it, via intermediate systems which only need to know about the instant in time. >>> >>> The TC39 working group at ECMA have developed a format which is a good basis for this work. >>> >>> It is anticipated that this document would be a companion to RFC3339 rather than a replacement, embedding an un-altered RFC3339 instant along with the contextual data. >>> >>> It is also within scope for this group to consider a minor update to RFC3339 to allow larger than 4 digit signed years, to enable representing times further into the past and future. >>> >>> Once this work is done it is anticipated that this working group will be short-lived, and once the one or two documents are published the working group will close down. >>> >>> Milestones: >>> * April 2021: Adopt draft describing a serialisation format for extended datetimes. >>> * July 2021: Submit the serialisation document to the IESG. >>> >>> -- >>> Bron Gondwana, CEO, Fastmail Pty Ltd >>> brong@fastmailteam.com >>> >>> >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > *Attachments:* > * signature.asc -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --9acd9cd7e6dd49c98e4005836ed68ea6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I think the idea is that TC39 doesn't want to standardise = something DIFFERENT than the rest of the world, so trying to get IETF to= go first makes sense.  Failing that, TC39 can just do its own thin= g and hope the rest of the world follows, but that means it doesn't get = a change to have as much outside review as the IETF process gives.

Bron.

On Thu, Apr 15, 2021, at 03:42, Eliot Lear wrote:
Just o= ne question:

Is= it necessary for both the IETF and TC39 to standar= dize this?

Eliot

On 14 Apr 2021, at 18:00, Bron Gondwana <brong@fastmailteam.co= m> wrote:

This was discussed in the DISPATCH meeting at IETF110: https://datatr= acker.ietf.org/doc/minutes-110-dispatch/

The conclusion of the discussi= on was:

* Kirsty (chair): Sounds like =
there's general agreement that a working group is
what's needed, we will take a final decision on the list and just confir=
m with
Patrick as co-chair before officially dispatching as such. The link to t=
he
charter is on list too, please take a look and see if you think a BoF is=
 needed
as the next step or a WG can begin right away.

So Murray (AD), do you thi= nk we have enough to request a working group be charted from the discuss= ion and the proposed charter text quoted below?

Thanks,

Bron.

On Fri, F= eb 19, 2021, at 15:20, Bron Gondwana wrote:
=
I've asked the chairs fo= r space on the next dispatch agenda to talk about dispatch for
=

https://datatrac= ker.ietf.org/doc/draft-ryzokuken-datetime-extended/

The authors have taken on board the idea that= we should extract the "obsolete RFC3339" and either remove it entirely,= or separate it into a document which does nothing but update RFC3339 wi= th support for a wider range of year values.  There will be an upda= ted version of this draft soon.

The dispatch chairs also asked me for some proposed charter text if w= e were to spin up a working group for this topic.  Here's that text= .

Cheers,

Bron.

Serialising Extended Data About Times and Events (= SEDATE)
----=

= RFC3339 defines a format t= hat can reliably express an instant in time, either in UTC or in a local= time along with the offset against UTC, however datetime data often has= additional context, such as the timezone or calendar system that was in= use when that instant was recorded. Particularly when using times for i= nterval, recurrence, or offset calculations, it's necessary to know the = context in which the timepoint exists.

It is valuable to have a serialisatio= n format which retains this context and can reliably round-trip the addi= tional context to systems which understand it, via intermediate systems = which only need to know about the instant in time.<= /span>

= The TC39 working group at = ECMA have developed a format which is a good basis for this work.=

It is anticip= ated that this document would be a companion to RFC3339 rather than a re= placement, embedding an un-altered RFC3339 instant along with the contex= tual data.

=
It is also within scope for this group to consider a minor update= to RFC3339 to allow larger than 4 digit signed years, to enable represe= nting times further into the past and future.<= span class=3D"font" style=3D"font-family:menlo, consolas, monospace, san= s-serif;">
Once this work is done it is a= nticipated that this working group will be short-lived, and once the one= or two documents are published the working group will close down.

Milestone= s:
* April 2= 021: Adopt draft describing a serialisation format for extended datetime= s.
* July 2021: Submit the seriali= sation document to the IESG.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


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


______________________= _________________________
dispatch mailing list

= Attachments:
  • signature.asc

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


--9acd9cd7e6dd49c98e4005836ed68ea6-- From nobody Wed Apr 14 12:28:55 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B093A1C9E for ; Wed, 14 Apr 2021 12:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sImTFIya79j for ; Wed, 14 Apr 2021 12:28:49 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E723A1CA0 for ; Wed, 14 Apr 2021 12:28:49 -0700 (PDT) Received: from [192.168.217.118] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FLCFW0XdtzyX4; Wed, 14 Apr 2021 21:28:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 14 Apr 2021 21:28:46 +0200 Cc: Eliot Lear , dispatch@ietf.org, "Murray S. Kucherawy" , Ujjwal Sharma , Shane Carr X-Mao-Original-Outgoing-Id: 640121326.444724-d51848473cf5d17fc2afcc0bc8e35448 Content-Transfer-Encoding: quoted-printable Message-Id: <3AEFDFA4-C55F-46A1-8602-51CE178BA551@tzi.org> References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> To: Bron Gondwana X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 14 Apr 2021 19:28:54 -0000 I know that on IETF mailing lists it is unusual to discuss what the = subject line says the discussion is about, but... (1) I think we are discussing date/time formats here, not date formats. (2) I think we are also discussing text string formats only, not formats = in general. If either of these assumptions is not true, I need to point to: * Calendar dates: RFC8943 [1], which has a compact (binary) format for = calendar dates in addition to the usual text-string one (based on RFC = 3339, of course) * Compact, complex (=E2=80=9Cextended=E2=80=9D) datetimes: = draft-bormann-cbor-time-tag [2], which has some elements of a date/time = format that go beyond tags 0 (text-string, RFC3339) and 1 (compact, = Posix) in RFC8949 [3]. Partially also inspired by [4]. What the latter needs next is a good TZDB [5] indexing mechanism (a.k.a. = time zone names [6]); a compact form would be a bonus here again. Just saying. Gr=C3=BC=C3=9Fe, Carsten [1]: https://www.rfc-editor.org/rfc/rfc8943.html#section-1.1.1 [2]: = https://www.ietf.org/archive/id/draft-bormann-cbor-time-tag-04.html#sectio= n-3.4 [3]: = https://www.rfc-editor.org/rfc/rfc8949.html#name-standard-date-time-string= [4]: https://www.rfc-editor.org/rfc/rfc8575.html#section-3 [5]: https://data.iana.org/time-zones/tz-link.html [6]: https://www.rfc-editor.org/rfc/rfc6557.html From nobody Wed Apr 14 15:45:57 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1023A230E for ; Wed, 14 Apr 2021 15:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=crPSPb1+; dkim=pass (2048-bit key) header.d=taugh.com header.b=DwMeIgct 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 kyPi7wLia-c4 for ; Wed, 14 Apr 2021 15:45:51 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A443A230C for ; Wed, 14 Apr 2021 15:45:50 -0700 (PDT) Received: (qmail 97312 invoked from network); 14 Apr 2021 22:45:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17c1d.6077709b.k2104; bh=S1nrEqssRBMDfgzgl0SGK4n+icvuNtSnnBNm4nM17oM=; b=crPSPb1+Fs5f9bkWjbxlz74GxZleULf+vJogr2a81Xq30doiuWmrwF4Z310IE1OQYOblNsGoVRvk0kQEgsmibULOXFgKi43Eb9E8izP5C8urwqiu0xWmJFAFPsOBnHUBtri1leCQole3l7eNclA6g7tkGiYxCj3FvlHrASAeWAVgoSf6svBdXUme6muVPfAXsmAv+2mVFYAzy3cwDpbmIFrFtZ+4Bj/fuOUNsPKIqltZwVA8lqBhja93Cr3IZJV8KgbuoO3X8Yp6UPfTDKcOvLJtGSHYsgM8v3bzs8acXvkGdZUhxSgpQcqQmrVEVb95x0V7QiqI/46dW6o+hg0ZHQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17c1d.6077709b.k2104; bh=S1nrEqssRBMDfgzgl0SGK4n+icvuNtSnnBNm4nM17oM=; b=DwMeIgctUVPiQm1tT4Vi0KGkC5gRtQsEr37kEm3kiXf4qd4nxxfzxm+AJ7lKniiabq76Mx2gk9ONyM+4XoP43eYtvggW65rbl/sgcYpm7lXtyKptTX2amqmNzdy+9JVeF5P0qL4W8iVfKQkxXLW9uEpQBwNZJ/MUm+2n3DV9wKyMFy8P2konhzRJE4iKxkQMFEYEEzvN5WTQ1nknDJipANzetE9hlpsueMU+AiGFHdnNGKbOLRl7LYcWOVTLWeOyYfQEIzsEE+oHzF8uc7+CML5NM0ujc29N17S/MvUPsf+L09yVOowtW2qoMQkbM5vXVMZ3t+x+/lxGQJc/wdxT+w== 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 Apr 2021 22:45:47 -0000 Received: by ary.qy (Postfix, from userid 501) id 41F7C72E67EC; Wed, 14 Apr 2021 18:45:45 -0400 (EDT) Date: 14 Apr 2021 18:45:45 -0400 Message-Id: <20210414224546.41F7C72E67EC@ary.qy> From: "John Levine" To: dispatch@ietf.org In-Reply-To: <0C8FFDA77AF247414013590D@PSB> 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] Proposed charter for extended date format 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, 14 Apr 2021 22:45:56 -0000 It appears that John C Klensin said: >spite of the I-D excluding intervals from its scope). I also >note that the I-D does not appear to show awareness of changes >in ISO 8601 in 2019 (including the addition of ISO 8601-2:2019). Is there a way to find out what ISO 8801-2 says without spending CHF 178? I'm interested but at this point, not THAT interested. (Arbitrage note, it's $225 or about CHF 207.) -- 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 From nobody Wed Apr 14 17:27:20 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9433A2628 for ; Wed, 14 Apr 2021 17:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbkIRFWTsdE8 for ; Wed, 14 Apr 2021 17:27:14 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410102.outbound.protection.outlook.com [40.107.141.102]) (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 69D2B3A2626 for ; Wed, 14 Apr 2021 17:27:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ckMYadtPWXcXogYLEihWz4jS5X3rPh6XFi7WNgQXJTvvERa+8L5BFRPTflnVPVYpU+sQdM4Py+iHdKjEgH0waKd46vevcpyIQHWUTP3PgCebIrarr8kymCjqJgNY3DGNMixWjOltUxgc2LA4eZfe9AFuuw0n7q9kGFG3r8QsX2sHi0cCQJHRVJJNygemNtxz4vAarxMFuqkYOmqiSLG8/wvoPCNLW89iSxV0YGGIyMAned41b7ULhzKQXJ2nIhgiVstjriM16U03q++7H3ZwyUZKbntr7WRkrWYvRS9UOVfYTm1DTLkxXJTAN2mmCylsW406a6LReVjtMb9e0jYSNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4xxA+KUin9xvTkhH804wOoVzQ3Mg8ZqVlL4nY+/Jsvk=; b=mkKKvD/AUkN4wl6IezugzsCvisJ+4hemtMIwRr8KJnFVm1dt7cuFOe2DEX0mDdmSEEgibMODw9pk8VXKg+rE/tFrlFYQI9NOyQ4UuHUJaiEezE4XU66NXOqLdU1oza9h+RNjDKaRUYe1hD5yb5JlR8sgp2FDQrRuITpZqxdVrJ5jKJzaMCCy9LzWnSYBws0uM6TSYQ/9Nrf/lZdp/E3g/s9h3HyrwsLknC5BVnf8gDNNmMI6Y8BMO2BOEXcfdVviiN0itOvL/3vmlFBwogLoIS2Jn3MNhz8GzwNor4LObZH9litAICrVrvCOwBjMKZom9Qr8wkk4UbFZQQt3ufMHcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4xxA+KUin9xvTkhH804wOoVzQ3Mg8ZqVlL4nY+/Jsvk=; b=h3u7UqYIeLytjx/6UtYDMQ/5oxhMu5d7oB6Rqj7gqQ459X/+LwwvS13k8NxYLcDsXiZRWwIhuKq4PGBtv16ANfDOKQ/nyOfQ+RmVlyAS7o4X76KOrviDLEire/4HEFgERlfowEIeVLoliJ4qgJPn+q00g8v74WyIT8hL1edME7k= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYXPR01MB1471.jpnprd01.prod.outlook.com (2603:1096:403:12::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Thu, 15 Apr 2021 00:27:07 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2%4]) with mapi id 15.20.4042.016; Thu, 15 Apr 2021 00:27:07 +0000 To: John Levine , dispatch@ietf.org References: <20210414224546.41F7C72E67EC@ary.qy> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Thu, 15 Apr 2021 09:27:03 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 In-Reply-To: <20210414224546.41F7C72E67EC@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [125.205.106.154] X-ClientProxiedBy: TY2PR02CA0068.apcprd02.prod.outlook.com (2603:1096:404:e2::32) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.5] (125.205.106.154) by TY2PR02CA0068.apcprd02.prod.outlook.com (2603:1096:404:e2::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Thu, 15 Apr 2021 00:27:07 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: af6940f4-1a13-4098-98f7-08d8ffa53385 X-MS-TrafficTypeDiagnostic: TYXPR01MB1471: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YtyTlaK/BltU2+ub966AzMqRj0UjFT5Hm9v2C5CctQr69Uvc2q+Z3lHRcYViEnl/VBLFcb+XftVOXZ8MMCv7TjOaJ2nNKulfA5bmo9X7DGzZ1ofpTjCDFfm/81SlLNIKdDHXF+e08O+x+Iz0Ig8Gpsh1Wu3nvtF09F2lm5Mdqhs0McY8lxVydVW3zBh4voVkoDzyuLkrWxsUt5LySaHgjvjcDAt57rBNmbJRD9Gfrw+2A0JktFKSFTZOyhycTh9/ajPSbV/qUGd7yfxpoHg2fPlWC5OZBWRh9uMmadMfgO5AwQ5102g2gkf0ub7d0L5UlYWcakLStXCxl/gScbegpn0BFaOEF1zYIHgmpJ/cK2WoyPwZWp1FYMfgO78Htdko2vjLnSXbhXBUf696NE7sgdJw2uh0I031U4ZtY3cjA6akw3/BRHZWZpWZOFoudJH1ug21E5+Jchw1EHKQ2fKMNmkIBkYIqNbGSGtEFsSRUv6lSoweKnYlXG8J61UUlIw4xnQ3RJnH5Z6NwyF1yWJDDqLdLNv2XfT1rFQlgJ4KmmLn5IQRFsyJH/KY6xXqs0JopIn2RugWEM+aUDyPXSBqvq3v3jFrAbjNW+XbGnuXNvht3/QIcKf9VLS7f5gvPwI0z5iSQcLrwwnXixllbCDXhf6h73X0SEha7OM4kbTGBJ1TAoAO+B0pQpKsB4OxC/JQe1h75BJDMzm6sxyMCtfBfff6aXwge485CjWHTpHLgE9QsHRxOT+AR1Zlc2G/qH1RkUdWNgG8ARwh+5k6i7p2J/JcRI5P5OAUsdo6I3Q8iGc= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(39840400004)(366004)(376002)(346002)(136003)(396003)(6486002)(52116002)(8676002)(4744005)(186003)(8936002)(53546011)(36916002)(956004)(2616005)(5660300002)(26005)(38350700002)(2906002)(316002)(38100700002)(31696002)(786003)(16576012)(31686004)(478600001)(66556008)(66476007)(86362001)(66946007)(6666004)(16526019)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?OUVZZmNyeUVZY2FIK29IMGFLQndnQVViWTVlRy80SzRTMmhCN05yZ3dOL2l4?= =?utf-8?B?Yy9md1NYZkVRUG1pQjZHN2dMby9UTnlBdjA3SjJydVhQbDJTQ3FyeFZBU3Jv?= =?utf-8?B?T1NxK1JyOFZYQW81aUVBc3EvV2FNK3hIOE84L2J0anJScUk3YjVQUGhmN0Mr?= =?utf-8?B?ek5vQ2xKYVBPeWJxUlM4V3NrYTdSR2xGNmVOQnlkMWhhaDNOQlFhcFJVdE9Y?= =?utf-8?B?SlUwWlJNUSsrZlRYWXV0NUZ4QkhEWU9mT0lDM05JN0NFSkxiTzU1T2x0WS90?= =?utf-8?B?QzhPYkl2U1JkZE9HNVpLdWM0Mk9KOWxQc01SVTZWWjc1V1JnQWhUTGQ0eVlM?= =?utf-8?B?OHNNaWJkMDJRNzF4RjlMYnRicFJxdW4rRWhTKzNMb2s0aWJvTUdUNEJtY3Yv?= =?utf-8?B?Z1IzS3FXWjc2QVRYSlRxUW4yNllXRFNxVWQvYzZGL2p0MGxnUlB6TlZsU2xD?= =?utf-8?B?WTFWcE5wb0ZCaUlseVBtREROMy9jNlJ2UXRMVFVQS0JzdUNEVGZkRHJtMm5q?= =?utf-8?B?S2xpQ0NlVEFXU0RWdTY1eks5aHU1RUpzcHI1QzB3d2hIYjZweVJEUFlCZEZB?= =?utf-8?B?SERVeHBuZEhGZ2ptOVNQWHFadjZyQU1oZDNlc3lNQTRrODA5NlF5eHdobGE1?= =?utf-8?B?S3pHODl4WnJPZjVhTFd0SEt2dVpGVDk3eUw5KzJOeDJZWVNuUjNhbjkxZFZ2?= =?utf-8?B?KytzbG5jaDhwWFBDY2wvdyt3UEtEUmZtQ1d2Mk1uQ2RlZ3IvUUNZQzk0TU04?= =?utf-8?B?OXJrZjNlMVc5V2VBRWk3RnZhaE5aU29VaTZjdVM0S1V6NStuejY0aUVJbE9W?= =?utf-8?B?NG5nK1hGbEhEUlV3bXJrU01zdU1Ra0E4ZTBLWGFNTUxGcEZ6L01ocXhSRXZT?= =?utf-8?B?QlR4Q2xCTU81bzVFYXB4YmppcmFRRjRwcklnMWVJWm9WbmdaV0M3UW9xTWpm?= =?utf-8?B?bFFIUHQ3eG9HMGUrMXMvTlZ4K216aXJkaHdSdEIrWkNWdlVMWTBLRWNMc0tP?= =?utf-8?B?Qi9aZWx1Wnpxbm1rOFMvdXJya3Q4VUEwcDU3WXNGcXEwUVlOK0FmRmlReTdl?= =?utf-8?B?N3NtM3VzaTdJWWRQbG9pSEhDUVRES3ZIK0xlQmNSNGgwSHc1bm9pZ3p6a1U2?= =?utf-8?B?MkFraVdRTGdrekFGcTBNVmJ1RTZYRmNVeS9oaFljNGhHRHQ2bERucjd2Znpw?= =?utf-8?B?cThTc3dJOHpVa0lLeDRDbXdhZmI2MlNVWFp2RktIVS9pbnc1ZFFsb0tQMGlp?= =?utf-8?B?RUJjeDBydTU4a05PdnNvdm5LTW1ZOGJYUDg1UXo1blBDdlJJRXFFNmhKU3hk?= =?utf-8?B?Slo2NlhmZGQvZVhZaE5sSDk1L0hKT0VXQytSRWJza2Y5Nm0wZTdDbzBPbThY?= =?utf-8?B?TlV4YTFPalhVTkNLVlJTRlVBN3F3dkRiWVpSWXVQYS9NSkdrRyt4Ly9Zc0E1?= =?utf-8?B?L2dYNGVFVVROdEhHN25sTjJCN3R4ZG9rSE1TQ0oweUkvTGZETlhKVU41QnFN?= =?utf-8?B?N3BkbHBONVVreXp0WDc5ZEc1ZG01Q2VKRUh1Y2tyb0JoREJJUlQxcGZNaUlh?= =?utf-8?B?UXV3bGFuaFgzVm5nLzA3UCtycGc4UXc2cFRhM0xXeElFa0JRUmIrbDNLYjFU?= =?utf-8?B?R3VqWDZsWUFlczhoTUtCRlp2M2xPWFhxaTFRV0s4QXluanF0UkRoT21UamlY?= =?utf-8?B?U2ZPWGVzeDkxcXZJNldPNnRZNXJkK0NyQnRTeml6dVMzTnNNazRLRjJ6Smhl?= =?utf-8?Q?qa/XkgJ3oMFCgK/QIDKv3FIXspmUe+WCS+3n+3Y?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: af6940f4-1a13-4098-98f7-08d8ffa53385 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2021 00:27:07.3877 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VJSX2zgXe2j4kVyXq9nEwtehkE8Xq60N5yHOT2cfckADWV5MbIdGDn0h37mXmT2UhfUQLVMVSThfetKUYmC13g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB1471 Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 15 Apr 2021 00:27:19 -0000 Hello John, On 2021-04-15 07:45, John Levine wrote: > It appears that John C Klensin said: >> spite of the I-D excluding intervals from its scope). I also >> note that the I-D does not appear to show awareness of changes >> in ISO 8601 in 2019 (including the addition of ISO 8601-2:2019). > > Is there a way to find out what ISO 8801-2 says without spending > CHF 178? I'm interested but at this point, not THAT interested. > (Arbitrage note, it's $225 or about CHF 207.) I think you meant ISO 8601-2:2019 (https://www.iso.org/standard/70908.html). Sells for 23'496 Yen in Japan. No Japanese translation (yet), these are usually cheaper, and are often sold in groups in book form, which makes them quite reasonable. Listed at 75 pages. In the past, $1/CHF 1/100 Yen per page was a good estimate for ISO standard prices, but apparently they have jacked up their rates considerably. Unclear if they want their standards to actually be bought and used :-(. Regards,    Martin. From nobody Wed Apr 14 17:34:00 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DA03A265A for ; Wed, 14 Apr 2021 17:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=12TB4Zjv; dkim=pass (2048-bit key) header.d=taugh.com header.b=VS65A8HH 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 QG2_OfwK39lp for ; Wed, 14 Apr 2021 17:33:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190D33A2655 for ; Wed, 14 Apr 2021 17:33:51 -0700 (PDT) Received: (qmail 12398 invoked from network); 15 Apr 2021 00:33:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=306c.607789ec.k2104; bh=HsNWdd+w2yGPEOE8TWSx3boeZVz/yi0csAdo/stVugg=; b=12TB4ZjvAoCDZtArzdzCEN40KJlL/iIO6UUlHN40JJEjvabdxxHQk1i5yBZ6alpZ6fsNT2WInAyon79ei/KeU4gXuib+qWt0YWVnGvCQ/b+E0OZyYZu+WoM3hcs0O0VGpzF5o9/prW8JMEqce9nmVGlbgVdFlxd+a0Y4zjWDHl36p6lEMYaaUAHlQe6Bk1j5knwQREJA+Bq9yRCbxEv9bxAS7a0wPRQjx9EutGZodka8/iEzMJMcRBaoocMhaGu4CpWIM7vx7uG8AQozM1ObW0DKyWNGfuTbx0TrDmg2PVGPqplGPAGQeAPGGYqugme8MAE+zQ/xme0Ba6GKp4ARTQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=306c.607789ec.k2104; bh=HsNWdd+w2yGPEOE8TWSx3boeZVz/yi0csAdo/stVugg=; b=VS65A8HHJG6JtfmfrgGsiHwqN+APvwk+VbjNrJK1BlVgVAQxAnIN6EA+MVUGSuPCsW66EYNom0XHYbvnj2VSVvO/1bU/fgcn6X5M9IMpC10N4Y8Ny9zMaBz2SFnJvei40dWMB1xsgoyJBlkxHGFXDeftCYyZqUEzY7wyyC70msakV2AH4IxfzIzgxoMa5KbuOpNXPO5rEwoPl8X4zWIKV6o3ve2Mgl9QhoC8wJTmtNdLx6RXhQrb7p+eXXXhZcRawHoOPDoBv1ZWWB9ktil7BEGeP+0OPDKBynDrTUQqzxzkBO0oIwjXAN8x0DLqiJN11rjWptGQk7IHAnxIxDr+GQ== 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; 15 Apr 2021 00:33:48 -0000 Received: by ary.qy (Postfix, from userid 501) id D42CE72E82DB; Wed, 14 Apr 2021 20:33:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 5D5E172E82BD; Wed, 14 Apr 2021 20:33:47 -0400 (EDT) Date: 14 Apr 2021 20:33:47 -0400 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Martin_J=2E_D=C3=BCrst?=" , "Dispatch WG" X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210414224546.41F7C72E67EC@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 15 Apr 2021 00:33:58 -0000 >>> in ISO 8601 in 2019 (including the addition of ISO 8601-2:2019). >> >> Is there a way to find out what ISO 8801-2 says without spending >> CHF 178? I'm interested but at this point, not THAT interested. >> (Arbitrage note, it's $225 or about CHF 207.) > > I think you meant ISO 8601-2:2019 Yes, of course. > (https://www.iso.org/standard/70908.html). Sells for 23'496 Yen in Japan. Still a little out of my range. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Apr 14 18:25:50 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9483A2802 for ; Wed, 14 Apr 2021 18:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09pspiCQXgqf for ; Wed, 14 Apr 2021 18:25:43 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE183A2800 for ; Wed, 14 Apr 2021 18:25:43 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lWqlE-000J3N-Mq; Wed, 14 Apr 2021 21:25:36 -0400 Date: Wed, 14 Apr 2021 21:25:31 -0400 From: John C Klensin To: Bron Gondwana , Eliot Lear cc: Ujjwal Sharma , dispatch@ietf.org, Shane Carr Message-ID: In-Reply-To: References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.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] Proposed charter for extended date format 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, 15 Apr 2021 01:25:48 -0000 Bron, I have heard that there is an alternate universe in which standards developers actually work with each other. That is often with the goal of producing better work than either could do separately or at least to avoid reinforcing the nasty comment (known in both worlds) to the effect that the nice thing about standards is that there are so many to choose from. For many years, the IETF was excluded from that universe because we were considered immature and were pushing ideas (you know, like packet switching and SMTP/822-based email) in which no one was interested. However, that period ended years ago and there were, in that universe, many years in which collaborations were possible and successful. In that universe, while some of those collaborations remain, it has become difficult to establish new ones because the IETF has concluded that working with other bodies on terms acceptable to them is just not worth the trouble, at least unless they come to us begging for such relationships. Instead, we just announce to them what we are doing, even if it is at variance with their published standards, and expect them to adjust. But, since we don't live in that universe (or at least I hope we don't), why not work out a collaboration with ECMA TC39 [1] and, ideally, a three-way one that includes ISO 154, and sort this out together, vastly reducing both the chance of one body standardizing something different from the rest of that world and, even more important, of messing it up? Another advantage of such an approach is that it tends to drop any bars to accessibility to each other's work in progress and other documents, thereby addressing the issue John Levine has raised. john --On Thursday, April 15, 2021 04:00 +1000 Bron Gondwana wrote: > I think the idea is that TC39 doesn't want to standardise > something DIFFERENT than the rest of the world, so trying to > get IETF to go first makes sense. Failing that, TC39 can just > do its own thing and hope the rest of the world follows, but > that means it doesn't get a change to have as much outside > review as the IETF process gives. > > Bron. > > On Thu, Apr 15, 2021, at 03:42, Eliot Lear wrote: >> Just one question: >> >> Is it necessary for *both* the IETF and TC39 to standardize >> this? >> >> Eliot >> >>> On 14 Apr 2021, at 18:00, Bron Gondwana >>> wrote: >>> >>> This was discussed in the DISPATCH meeting at IETF110: >>> https://datatracker.ietf.org/doc/minutes-110-dispatch/ >>> >>> The conclusion of the discussion was: >>> >>> * Kirsty (chair): Sounds like there's general agreement that >>> a working group is > what's needed, we will take a final decision on the list and > just confirm with Patrick as co-chair before officially > dispatching as such. The link to the charter is on list too, > please take a look and see if you think a BoF is needed as the > next step or a WG can begin right away. >>> >>> So Murray (AD), do you think we have enough to request a >>> working group be charted from the discussion and the >>> proposed charter text quoted below? >>> >>> Thanks, >>> >>> Bron. >>> >>> On Fri, Feb 19, 2021, at 15:20, Bron Gondwana wrote: >>>> I've asked the chairs for space on the next dispatch agenda >>>> to talk about dispatch for >>>> >>>> https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-e >>>> xtended/ >>>> >>>> The authors have taken on board the idea that we should >>>> extract the "obsolete RFC3339" and either remove it >>>> entirely, or separate it into a document which does nothing >>>> but update RFC3339 with support for a wider range of year >>>> values. There will be an updated version of this draft >>>> soon. >>>> >>>> The dispatch chairs also asked me for some proposed charter >>>> text if we were to spin up a working group for this topic. >>>> Here's that text. >>>> >>>> Cheers, >>>> >>>> Bron. >>>> >>>> Serialising Extended Data About Times and Events (SEDATE) >>>> ---- >>>> >>>> RFC3339 defines a format that can reliably express an >>>> instant in time, either in UTC or in a local time along >>>> with the offset against UTC, however datetime data often >>>> has additional context, such as the timezone or calendar >>>> system that was in use when that instant was recorded. >>>> Particularly when using times for interval, recurrence, or >>>> offset calculations, it's necessary to know the context in >>>> which the timepoint exists. >>>> >>>> It is valuable to have a serialisation format which retains >>>> this context and can reliably round-trip the additional >>>> context to systems which understand it, via intermediate >>>> systems which only need to know about the instant in time. >>>> >>>> The TC39 working group at ECMA have developed a format >>>> which is a good basis for this work. >>>> >>>> It is anticipated that this document would be a companion >>>> to RFC3339 rather than a replacement, embedding an >>>> un-altered RFC3339 instant along with the contextual data. >>>> >>>> It is also within scope for this group to consider a minor >>>> update to RFC3339 to allow larger than 4 digit signed >>>> years, to enable representing times further into the past >>>> and future. >>>> >>>> Once this work is done it is anticipated that this working >>>> group will be short-lived, and once the one or two >>>> documents are published the working group will close down. >>>> >>>> Milestones: >>>> * April 2021: Adopt draft describing a serialisation format >>>> for extended datetimes. * July 2021: Submit the >>>> serialisation document to the IESG. >>>> >>>> -- >>>> Bron Gondwana, CEO, Fastmail Pty Ltd >>>> brong@fastmailteam.com >>>> >>>> >>> >>> -- >>> Bron Gondwana, CEO, Fastmail Pty Ltd >>> brong@fastmailteam.com >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> *Attachments:* >> * signature.asc > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > From nobody Wed Apr 14 19:44:27 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159B83A2A9F for ; Wed, 14 Apr 2021 19:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=sTacnOCM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sFEahIxy 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 OmgLtd0LfBmG for ; Wed, 14 Apr 2021 19:44:20 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59FD3A2AA0 for ; Wed, 14 Apr 2021 19:44:20 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id CD49812EC; Wed, 14 Apr 2021 22:44:16 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 14 Apr 2021 22:44:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=p7QH tcfyPRUmCARo9hrytqtRkMlRfx988v+tr3+3oXI=; b=sTacnOCM0MK+7i5a1CSZ 3Ag1fYvZOhNcZ7sS+HNux0T7sTG+PkN2bVna4WtGIzHHYZpaLg8lD5lw8M/syECN 2va7PRMawcdENXH0atyvBmiotzhcB+CTDz+1rehwHQnoQt0DIkn8hXu79NLaWCwV oDQ+DfDQRlFecudzZI8vJcdw+dSZE/8aJhIqsCzmIwBNltoT0nZvdrTRriY5MKfM N2jgU18AB5KV5nh3TmmIKaur4qj3K8dZP+9JdOflLztULR4afS15fgzcpSfa9B9L zBQcptsdkaBp6o4TT/dpykMl8WN7JXaoyXOZrByk1cM7OgfTY8bQcCFKVmo3RTyv Og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=p7QHtc fyPRUmCARo9hrytqtRkMlRfx988v+tr3+3oXI=; b=sFEahIxylO0O20sqhD32yr TKJz1Kv3au0cFXsdmF01xjOHsTG7SouFwu1roi3uaXILFIAc4Ln4xF4bfXtklpri Szvwbp7Bmj8XxpulEsPqQ3w1GF/GSSJhV1dvJU0FajQdA1cSs/G4UX+Xg5byt8FQ j8h7nkcdoIwG0sO5fPKbxNJHNzCK82WrGqUkUn3poTnKOwI6g6o4/0pQHsh7uKS7 8EKg1XfB91SrP2sSW1JfNPW4nv1ZLz2dF50MU5HbghseAT6ltwUJ1m9IMJSNSd6H NR3fjrziw1g/61bgigy8HcZbVkwXDvoqLlMaV2vzoLOO98DPBBBt8jbMO6fBdG2Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudelvddgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepvdduueeihefgvdehueeujeejuedugfeigfevteefleet feffgfdtjeejgfeuuddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8C37B260005F; Wed, 14 Apr 2021 22:44:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-378-g5ea5579899-fm-20210412.001-g5ea55798 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> Date: Thu, 15 Apr 2021 12:43:54 +1000 From: "Bron Gondwana" To: "John C Klensin" , "Eliot Lear" Cc: "Ujjwal Sharma" , dispatch@ietf.org, "Shane Carr" Content-Type: multipart/alternative; boundary=968d9317eefd4a0e9b53c2a2f0d9d100 Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 15 Apr 2021 02:44:26 -0000 --968d9317eefd4a0e9b53c2a2f0d9d100 Content-Type: text/plain On Thu, Apr 15, 2021, at 11:25, John C Klensin wrote: > Bron, > > I have heard that there is an alternate universe in which > standards developers actually work with each other. What a novel idea. > That is > often with the goal of producing better work than either could > do separately or at least to avoid reinforcing the nasty comment > (known in both worlds) to the effect that the nice thing about > standards is that there are so many to choose from. No shit. > For many years, the IETF was excluded from that universe because we were > considered immature ... and this thread suggests that maybe we still are. > But, since we don't live in that universe (or at least I hope we > don't), why not work out a collaboration with ECMA TC39 [1] and, > ideally, a three-way one that includes ISO 154, and sort this > out together, vastly reducing both the chance of one body > standardizing something different from the rest of that world > and, even more important, of messing it up? You may have noticed that this work was brought to the IETF by the people at ECMA TC39. They also brought it to CalConnect who have a collaboration with ISO154. Everyone in CalConnect agreed that it would be great it the IETF published the work as an extension to or replacement of RFC3339, so that it was generally available to more than just javascript as it would be if it was just TC39, and available to the public without paying, which it wouldn't be if it was just ISO publishing it. Fast forward to actually bringing it here. The first feedback was "don't replace 3339, because many places just need a point in time and we don't want to make it more complex to parse when used there". Fine. Then we were told to bring it to DISPATCH, so I helped the TC39 people do that. I also attended the TC39 meeting where they were about to declare this work "done" and I asked them to hold for a few months, thinking that the IETF might actually be able to do this one fairly quickly. I'm leaning towards the conclusion that the IETF is still constitutionally incapable of cooperating with other standards bodies given that experience that TC39 have had here. Otherwise I've had a complete failure at persuasion, which is quite possible. Either way, unless the IETF takes a crap or gets off the pot on this topic pretty soon, TC39 is going to have to go ahead and standardise this work without our input, because they can't wait forever. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --968d9317eefd4a0e9b53c2a2f0d9d100 Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Thu, Apr 15, 2021, at 11:25, John C Klensin wrote:
Bron,

I have heard that there is an alternate universe in= which
standards developers a= ctually work with each other. 

What a n= ovel idea.

That is
often with the goal= of producing better work than either could
do separately or at least to avoid reinforcing the nasty = comment
(known in both worlds= ) to the effect that the nice thing about
standards is that there are so many to choose from.  <= br>

No shit.

For many years, the IETF was excluded from th= at universe because we were
c= onsidered immature

... and this thread sugg= ests that maybe we still are.

But, since we don't live in that universe (or at lea= st I hope we
don't), why not = work out a collaboration with ECMA TC39 [1] and,
ideally, a three-way one that includes ISO 154, and = sort this
out together, vastl= y reducing both the chance of one body
standardizing something different from the rest of that world<= br>
and, even more important, of = messing it up?
<= br>
You may have noticed that thi= s work was brought to the IETF by the people at ECMA TC39.  They al= so brought it to CalConnect who have a collaboration with ISO154.  = Everyone in CalConnect agreed that it would be great it the IETF publish= ed the work as an extension to or replacement of RFC3339, so that it was= generally available to more than just javascript as it would be if it w= as just TC39, and available to the public without paying, which it would= n't be if it was just ISO publishing it.

Fast forward to = actually bringing it here.  The first feedback was "don't replace 3= 339, because many places just need a point in time and we don't want to = make it more complex to parse when used there".  Fine.

Then we were told to bring it to DISPATCH, so I helped the TC39 peopl= e do that.  I also attended the TC39 meeting where they were about = to declare this work "done" and I asked them to hold for a few months, t= hinking that the IETF might actually be able to do this one fairly quick= ly.

I'm leaning towards the conclusion that the IETF is s= till constitutionally incapable of cooperating with other standards bodi= es given that experience that TC39 have had here.  Otherwise I've h= ad a complete failure at persuasion, which is quite possible.
=

Either way, unless the IETF takes a crap or gets off the pot on th= is topic pretty soon, TC39 is going to have to go ahead and standardise = this work without our input, because they can't wait forever.
<= div style=3D"font-family:Arial;">
Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--968d9317eefd4a0e9b53c2a2f0d9d100-- From nobody Wed Apr 14 19:45:58 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6CD3A2AAE for ; Wed, 14 Apr 2021 19:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=oQWZhWuk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jZvTr9rC 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 9-5W-loKp9el for ; Wed, 14 Apr 2021 19:45:51 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99293A2AAB for ; Wed, 14 Apr 2021 19:45:51 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id E73561313; Wed, 14 Apr 2021 22:45:47 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 14 Apr 2021 22:45:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=Gjnm wgMZFTaLKEDOU7HA/otbxwfD18Itbgkp/QS5yp4=; b=oQWZhWuk8zCyw21/Fuvw w3YtH1Pixts3weu2mZ6Vizw0yKtR/T8s81tdQdlUK5yn3aFfass0kCOqqgB9iGJ3 6QzoGUvXJKvCstbduWG8nJhgGSu3P3gyi+Ha6kf0WUPcaRNCk5M2uGeG5Rk9rUPk 2yp4KI0yLDq10Qkn723FzdcfFPaSD/xqc/u8ez+8buBoeq9ZaOg/XUF0vX3TNKqh /IGVXSXqrpfcn1jVAbDvtddOl+Afl/wTXhRbmCHGw+TB7751EFS8+nqXT1IH8+EM jPE2N0RBIFEwilmX1WkTtckqmdHoYYjefSExVhH29V9b2Ohb7CMCnLQQRfeJsuVX 0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Gjnmwg MZFTaLKEDOU7HA/otbxwfD18Itbgkp/QS5yp4=; b=jZvTr9rCjZSasdyS0wReNW YpGgk/hM42x8/qWHMSi4pSF2IEg2wTdqF4ZMaBpgNYpk1NVtDIjVVr5n+lncKn5j /QF38IeZ+ZN9fqA08CM2Snfl+WonvWTjTlbz03vsHeViNdPNsw94N2hVSs0nk6/J hwIoTnlekQGSjz64HyHJ99eli6TEI4gX5Bn5vAsSAMvrbjaHy9f5k4P4cM0GUH7S vMVyyRH8JyAm8UHnM9qNH/XtCWo19nboEOzpBxORA1Whp8N6AvVZQE2RphAg9gXP VIKYrztgxaOrjUTgi7IXcnG1GUNK0BY7c0nHOskjg6JU9LkPs4y5fRqDXl/yUyvg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudelvddgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepvdduueeihefgvdehueeujeejuedugfeigfevteefleet feffgfdtjeejgfeuuddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B6B9C260005F; Wed, 14 Apr 2021 22:45:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-378-g5ea5579899-fm-20210412.001-g5ea55798 Mime-Version: 1.0 Message-Id: <9ec39fdc-315a-4a55-b48c-f15eb870078a@dogfood.fastmail.com> In-Reply-To: <3AEFDFA4-C55F-46A1-8602-51CE178BA551@tzi.org> References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> <3AEFDFA4-C55F-46A1-8602-51CE178BA551@tzi.org> Date: Thu, 15 Apr 2021 12:45:25 +1000 From: "Bron Gondwana" To: "Carsten Bormann" Cc: "Eliot Lear" , dispatch@ietf.org, "Murray S. Kucherawy" , "Ujjwal Sharma" , "Shane Carr" Content-Type: multipart/alternative; boundary=87214c33410943fdae3a7628ebaa0cee Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 15 Apr 2021 02:45:57 -0000 --87214c33410943fdae3a7628ebaa0cee Content-Type: text/plain On Thu, Apr 15, 2021, at 05:28, Carsten Bormann wrote: > I know that on IETF mailing lists it is unusual to discuss what the subject line says the discussion is about, but... > > (1) I think we are discussing date/time formats here, not date formats. > > (2) I think we are also discussing text string formats only, not formats in general. Yes - this was all discussed during the DISPATCH call, you are correct - those two points are the intent. If the proposed charter is unclear on this then I would welcome suggested text changes. Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --87214c33410943fdae3a7628ebaa0cee Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Apr 15, 2021, at 05:28, Carsten Bormann wrote:
=
I know that on IETF mailing lists it is unusual to discus= s what the subject line says the discussion is about, but...

(1) I think we are discussing date/time formats here, not date forma= ts.

(2) I think we are also discussing text string format= s only, not formats in general.

Yes - this w= as all discussed during the DISPATCH call, you are correct - those two p= oints are the intent.

If the proposed charter is unclear = on this then I would welcome suggested text changes.

Than= ks,

Bron.

=

--
  B= ron Gondwana, CEO, Fastmail Pty Ltd
&n= bsp; brong@fastmailteam.com

=

--87214c33410943fdae3a7628ebaa0cee-- From nobody Wed Apr 14 20:18:51 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8893A0060 for ; Wed, 14 Apr 2021 20:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=UV0DNppV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JFvj63x8 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 ILDtMDs0U8Qp for ; Wed, 14 Apr 2021 20:18:44 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8733A003F for ; Wed, 14 Apr 2021 20:18:44 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 1CA7E12D2 for ; Wed, 14 Apr 2021 23:18:43 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 14 Apr 2021 23:18:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=QXLKhTZ YmDBXbrjNA6NRlMbAs9nXTZZHfzAl4pkUc8Y=; b=UV0DNppVFe5ZMMMoiMShhM9 nG7NjoQMSQAxg74h3zIyQdEIy1DczaX8FJzxJNfWctmBGKBC2FwBxpS+VPbwsGdn eILC4xJGm/JxK2BgNpmj1IyNk/Xr+ckP4/1094zt+KDHEEL/xiiNNEIYisXmwjFF yiier3bvnt+D3VWJ3hu3zrryILsIBQz+49lJ8PI81XZS51+R8cTVmFdqNnxTPw7k cEEevURMMJe8iiEQPTgs1+FFho2p0/zRrPgT2sCVfduJ+UC5zVGU+SdG35OJhmdM VMR0RufWm60/bLgdQbk8BPASKHr0xBKgqeqfgJolCc71uRJUXE2rZXkE0adqTVg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=QXLKhT ZYmDBXbrjNA6NRlMbAs9nXTZZHfzAl4pkUc8Y=; b=JFvj63x8tSpRZIjrrl7BLL TCIindJGFjZVFUhVp+CwDq5B3smIBB2dDAUNMEYfi49reWB36lbo27kpdd5P42Es GFUJZq9xzwyTd3ecZtArxxjRAqzbEtydnanrjIcTtKsvnsKQwHC2VswAuwguH42O IQZeRjQkOeWsuNFEc7DKag87RQs1x5TbHv/Hgq2BFqAFm0tpbu0PnGFllI0S0wi5 uCeVWS42nv1qvxl5gM0L/7cculrptCjekUNxiV/KO//NexaAtUFPpq0iIzqdyhZs T6OFoP0k1TcXgW4XDlZQecfwOMGLdt1A+z1SJLfW5kBBgZa6otZMPTueANXe2dzA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudelvddgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvudeuieehgf dvheeuueejjeeuudfgiefgveetfeelteeffffgtdejjefgueduvdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CC885260005F; Wed, 14 Apr 2021 23:18:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-378-g5ea5579899-fm-20210412.001-g5ea55798 Mime-Version: 1.0 Message-Id: In-Reply-To: <20210414224546.41F7C72E67EC@ary.qy> References: <20210414224546.41F7C72E67EC@ary.qy> Date: Thu, 15 Apr 2021 13:18:21 +1000 From: "Bron Gondwana" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=421491c5b5734196916d5b893bda7d00 Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 15 Apr 2021 03:18:50 -0000 --421491c5b5734196916d5b893bda7d00 Content-Type: text/plain On Thu, Apr 15, 2021, at 08:45, John Levine wrote: > It appears that John C Klensin > said: > >spite of the I-D excluding intervals from its scope). I also > >note that the I-D does not appear to show awareness of changes > >in ISO 8601 in 2019 (including the addition of ISO 8601-2:2019). > > Is there a way to find out what ISO 8801-2 says without spending > CHF 178? I'm interested but at this point, not THAT interested. > (Arbitrage note, it's $225 or about CHF 207.) I have a draft of approximately what was published which is available to CalConnect members as part of our involvement with ISO, and I had a look through it just now to double-confirm my memory. It says very little which is relevant to this work - most of the changes are around ways to specify ambiguous dates or period longer than a day (e.g. 2021-W15 is the week that we are currently in, 2021-34 represents the time period from March 1 to June 30 this year, XXXX-11-26 represents my birthday without specifying a year). In particular, it doesn't do anything with timezones, calendar scales or calendar systems - it's Gregorian only. So apart from the greater-than-4-digit year problem, there's nothing in ISO8601-2 which would benefit this work. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --421491c5b5734196916d5b893bda7d00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Apr 15, 2021, at 08:45, John Levine wrote:
It appears that John C Klensin  <john-ietf@jck.com> said:
>spite of the I-D excluding intervals from= its scope).  I also
>= ;note that the I-D does not appear to show awareness of changes
>in ISO 8601 in 2019 (including th= e addition of ISO 8601-2:2019).

Is there a way to find ou= t what ISO 8801-2 says without spending
CHF 178?  I'm interested but at this point, not THAT int= erested.
(Arbitrage note, it'= s $225 or about CHF 207.)

I have a draft of = approximately what was published which is available to CalConnect member= s as part of our involvement with ISO, and I had a look through it just = now to double-confirm my memory.

It says very little whic= h is relevant to this work - most of the changes are around ways to spec= ify ambiguous dates or period longer than a day (e.g. 2021-W15 is the we= ek that we are currently in, 2021-34 represents the time period from Mar= ch 1 to June 30 this year, XXXX-11-26 represents my birthday without spe= cifying a year).

In particular, it doesn't do anything wi= th timezones, calendar scales or calendar systems - it's Gregorian only.=

So apart from the greater-than-4-digit year problem, the= re's nothing in ISO8601-2 which would benefit this work.

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


--421491c5b5734196916d5b893bda7d00-- From nobody Thu Apr 15 09:17:38 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082083A259E for ; Thu, 15 Apr 2021 09:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.099 X-Spam-Level: X-Spam-Status: No, score=-17.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFgiz0nGIRz7 for ; Thu, 15 Apr 2021 09:17:32 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 A11013A259D for ; Thu, 15 Apr 2021 09:17:32 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id y2so24666914ybq.13 for ; Thu, 15 Apr 2021 09:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=vGHVyrbAJm6tRcF27mT1mpF5E+vPGYk+CoIdV/iwDRY=; b=wDVHa86gs29yiGujPcrbPo9KUOwTBlR5arACtVClvcQITywXZhxJJhpoWkghrpj0Ja M9QuzEnBhEflIBGi/TxSE5KkV7k69KgSgR0l0xgVXeaAGHa60iOkw2BHHv8IkT2Bys8J d94xy7n1M0MzSR0DWabtVAXnXgFSTzDGHs54PJcCWtuxRc7i/LOhHgu31mHYlBLicB3X a7sv+srrAWieC7xVVSbU/qycQIDilNIbmP0IxhWhcpa2CjehkR0Z7AdojJUbAgaGAFrh 9uKrSLpjKpXunsfklxU60XspmHNbrUYiCXsVLHUaCT7SO1ZNhHVY2yAyBt4gi8IfO9Fm IyPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=vGHVyrbAJm6tRcF27mT1mpF5E+vPGYk+CoIdV/iwDRY=; b=JWdiDZw042UApDZ6Gr+cAQALZvol+WV6NvCEctZ5URiP47/8hK7VEIgug0AAdsD3rs 3HM/Jk1+GzT05F5vFbsQoneXBNReb/QhccmMSou1+lC489ryJzDKc7MIoFpOxnZFdlLj nnqfRxMCCx2MAjiwF27E6cTrVHbnvVcgnUxSKJdxaVEaIUYoE5qz3AlJlCeUOgTVscbN BJS0517rZhVYhxrcF8r3XgiAUcnmX8ZLQnjwOUGWUKfCji3UndYoKeOZhI5JOh194Q7P otw4j9D1uGyAXhVfekgFcrUqV3xMuOaIo6sPr2CUl/78sk4N2q9dsHV45x8Ht/OijvvZ vFQw== X-Gm-Message-State: AOAM533Yfck4TcHA4HSpPkEby4V1xBq8iGnYMzB9W+33hFYK/CT6kzHq dpksxRO5cuS39QIcZ55oOVLvUAvv2Z7fVzdRtcJTaaw7FeCWDWO8dNw= X-Google-Smtp-Source: ABdhPJw94Oio0XvxmUV+7rSwdd2MqhqPRnDPOEZtiT7cyPlT/6XqLYy8M7tzcaza5EPXqHFuLmMd7KxRW8WK7U2F59k= X-Received: by 2002:a25:aac3:: with SMTP id t61mr5165575ybi.405.1618503450509; Thu, 15 Apr 2021 09:17:30 -0700 (PDT) MIME-Version: 1.0 From: Mathias Bynens Date: Thu, 15 Apr 2021 18:17:19 +0200 Message-ID: To: DISPATCH WG Cc: Kirsty P , Myles Borins , "Matthew A. Miller" Content-Type: multipart/alternative; boundary="0000000000003cc13305c0053355" Archived-At: Subject: [dispatch] draft-ietf-dispatch-javascript-mjs-08 available 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, 15 Apr 2021 16:17:37 -0000 --0000000000003cc13305c0053355 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, Based on feedback on the 07 revision [1], we=E2=80=99ve made changes that a= re now available in revision 08: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ This new draft aims to address the feedback and resolve those discussions. We believe this addresses the last remaining blockers for the proposal, i.e. that this draft is the final version, ready for formal publication. In case it's easier to review, here's the diff between the previous and current versions: https://github.com/linuxwolf/bmeck-ids/compare/d211fb46c8bbf785327bee22e519= df1cefb64e28..HEAD#diff-1ffa50f1910aad909e9db0012b29e30eabbf0a49f53b86ade1c= 38a77574989ca Please take a look and let us know if you have any further comments! [1]: https://mailarchive.ietf.org/arch/browse/dispatch/?gbt=3D1&index=3DRZoQ1BhN= -Z-Ld9zbJ_mmxxPndOE --0000000000003cc13305c0053355 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

Based on feedback on th= e 07 revision [1], we=E2=80=99ve made changes that are now available in rev= ision 08:=C2=A0https://datatracker.ietf.org/doc/dra= ft-ietf-dispatch-javascript-mjs/

This new draf= t aims to address the feedback and resolve those discussions. We believe th= is addresses the last remaining blockers for the proposal, i.e. that this d= raft is the final version, ready for formal publication.

=

Please take a look and l= et us know if you have any=C2=A0further comments!

--0000000000003cc13305c0053355-- From nobody Fri Apr 16 02:38:20 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAA63A1E51 for ; Fri, 16 Apr 2021 02:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-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=igalia.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 bVNBH-D-NbGM for ; Fri, 16 Apr 2021 02:38:12 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 352C83A1E50 for ; Fri, 16 Apr 2021 02:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=lGpGn3eo7bLT7mFyPeSKLTiBWXgaaIkhMNay/ypkNXs=; b=GQZV5mj0MGiCVPURme9NEH/amKy4Lk5IdEISOy2MzzKJTeHmDj+Llovi5ttGzYRxLZA2BgKysl+3Myl0Mcifct3mnPjzUjXbWnem95ikDFU41let9NRWNwjHmsKGzF2KPig+lXpv0KLGx8rTUlixtDZbx0+qbgQCB/2NhQSykrmp8zPL9G6oVVPHoBtk94enkAAbLshc3Icrx8CHOLfgYI6f2kIEXRW836wTXgFixMWLUhNC1+rGgXIXa5CcS5do+DD2eUwItRyiSAvFYh+wEC3xXip2nDYTzIN6T5HCCTo3grMB9cbozU6xnHZ+p/epkLY7VHdyGyP7716FewPpWw==; Received: from [183.83.213.40] (helo=[192.168.0.190]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1lXKvO-0004GF-LE for ; Fri, 16 Apr 2021 11:38:07 +0200 To: dispatch@ietf.org References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> From: Ujjwal Sharma Organization: Igalia S.L. Message-ID: Date: Fri, 16 Apr 2021 15:07:53 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 16 Apr 2021 09:38:19 -0000 Hi John! On 15/04/2021 06.55, John C Klensin wrote: > But, since we don't live in that universe (or at least I hope we > don't), why not work out a collaboration with ECMA TC39 [1] and, > ideally, a three-way one that includes ISO 154, and sort this > out together, vastly reducing both the chance of one body > standardizing something different from the rest of that world > and, even more important, of messing it up? Another advantage > of such an approach is that it tends to drop any bars to > accessibility to each other's work in progress and other > documents, thereby addressing the issue John Levine has raised. I'm afraid I don't quite understand what you mean here? This *is* a collaboration with ECMA TC39. We are TC39 delegates and the champions of the Temporal proposal (https://github.com/tc39/proposal-temporal/#champions) that deals with the improvements around date-time handling in ECMAScript. There is consensus among the TC39 delegates that this work should end up in a standards body like the IETF before we proceed with it, as would be evident from the discussions during plenary (notes at https://github.com/tc39/notes/blob/master/meetings/2021-03/mar-9.md#temporal-for-stage-3, search for "IETF" or my initials, "USA"), so this effort is already a collaborative one between TC39 and IETF. Regarding ISO, we have brought this to the notice of the folks working on ISO8601 and CalConnect who seem to be happy with this generally, but perhaps we could work to get them more in the loop if needed? Cheers, Ujjwal -- Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, TC39 Delegate, Node.js Core Collaborator and Speaker From nobody Fri Apr 16 02:48:43 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E503A1EB5 for ; Fri, 16 Apr 2021 02:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 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 neGVMIBN5kgJ for ; Fri, 16 Apr 2021 02:48:37 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22C93A1EB2 for ; Fri, 16 Apr 2021 02:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1547; q=dns/txt; s=iport; t=1618566516; x=1619776116; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=T4aXS4OFiFer4/Q4vXIVmVlek7B2h4qui/InSccmuM4=; b=Oc5JIGrkjyFeBlPChJM/NJyJRnSc3bk/PT/lnFzBvehO+xQgTs2m7p0k XLoYfhpIAsgHYnx7YCBTPaNLMSuaMzFCVLvpVwLG81lntZ4rrs57EfQGY HEsiTD9khrjiOFuZkfjdVIvE0uSLgxml3kksPrjHpUEbsgStb3zMaN9L/ Q=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AiAACHXHlglxbLJq1aHAEBAQEBAQcBARIBAQQEAQGCA?= =?us-ascii?q?AUBAQsBgyFWAScSMYRDiQSISCiaa4F8BAcBAQEKAwEBKgoEAQGEUAKBdCY2B?= =?us-ascii?q?w4CAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFohVANhkQBAQEDASNRB?= =?us-ascii?q?QULCw4KKgICVwYTgnEBgmYhD6toeYEygQGDPwEDAhEPc4UICgaBOQGBUowCQ?= =?us-ascii?q?4ILgToMEIIwLz6CYAIChHU1gisEhAGBS4EpnVOdB4MWgz+BRoRikx8EH4M8E?= =?us-ascii?q?pBmLZAeoQqTSIQBAgQGBQIWgVsKJ4FbMxoIGxVIDw4Bgj4+EhkOjjiDV4pbP?= =?us-ascii?q?wMvOAIGAQkBAQMJjQ4BAQ?= IronPort-HdrOrdr: A9a23:cpreKqlihOUILuNG2SeP46XwsV7pDfKu3DAbvn1ZSRFFG/Gwvc rGpoV56TbfjjENVHY83e2RIaXoex/h3LN8/IV5B9afdSb8vm/AFutfxKvkhwbtAijvstNavJ 0BT4FbBMfrBVZ3yeb2iTPUL/8FwN2KtJ+lnv3fyXAFd25XQppt5Qt4FQqXe3ceLGJ7LKE0G5 aG6s1MqyDIQwVzUu2AGnIHU+LfzuekqLvaZ3c9dnwawTjLqTup7bLgeiLouis2Yndo3aoo93 TDnkjf4Kiu2svLrCP05iv084lcnsfnx594IPG0zuIRKjnql2+TFeNcZ4E= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,226,1613433600"; d="asc'?scan'208";a="35102900" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Apr 2021 09:48:32 +0000 Received: from [10.61.144.102] ([10.61.144.102]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13G9mVsb024344 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Apr 2021 09:48:32 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_068A48F8-830F-442D-A222-5A9081A8C7C8"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 16 Apr 2021 11:48:31 +0200 In-Reply-To: Cc: dispatch@ietf.org To: Ujjwal Sharma References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.102, [10.61.144.102] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 16 Apr 2021 09:48:42 -0000 --Apple-Mail=_068A48F8-830F-442D-A222-5A9081A8C7C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ujjwal, > On 16 Apr 2021, at 11:37, Ujjwal Sharma wrote: >=20 > There is consensus among the TC39 delegates that this work should end = up > in a standards body like the IETF before we proceed with it, as would = be > evident from the discussions during plenary (notes at > = https://github.com/tc39/notes/blob/master/meetings/2021-03/mar-9.md#tempor= al-for-stage-3, > search for "IETF" or my initials, "USA"), so this effort is already a > collaborative one between TC39 and IETF. That=E2=80=99s what I wanted to read. Thanks, Eliot --Apple-Mail=_068A48F8-830F-442D-A222-5A9081A8C7C8 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmB5XW8ACgkQh7ZrRtnS ejPb1QgAkSyK8tQUPL7zK3PhBYcjW746oZV0PHaKjKpNMoWRRiqGPXllnQsTn77O gUOyRfU8KA7UfaxvDIZPd2zKAa0WdmYV3aEnxeBy71KWf2DmtV2lL7EOBb+vPv7e w3VKRzgvev06OPgnI+wB188pV319SjoGS7jjrfsSOl9cEAjB8z5HXR5w1u6T4Rei +g4kA8CQVPasoin9x2nEXk7BJ0xu7c8zG/LXAhlr29AlyvvrAM4bBbkxP8/jO5uB osKWBYybmFQmC1ffKYOThqw4UrnNIntaOloAsIDRZp3a7hd+5CGiIgWG+GvY+RFk kfnNpBTE89ylmV4uCaSYDz+JZe0UGA== =mzt8 -----END PGP SIGNATURE----- --Apple-Mail=_068A48F8-830F-442D-A222-5A9081A8C7C8-- From nobody Tue Apr 20 06:21:10 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29FC3A2276 for ; Tue, 20 Apr 2021 06:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_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 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 FQlvqyOsH7Wl for ; Tue, 20 Apr 2021 06:21:04 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1723A2274 for ; Tue, 20 Apr 2021 06:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27825; q=dns/txt; s=iport; t=1618924863; x=1620134463; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ni7V3t57j9GY9tpvc98N+60pi5vJ7VWpWgTc01Ju670=; b=Z4lYeD/etf9+OmXoCNiPy67HY82FvfcDn+fG0JevammR6pr3v2JOmv4J +Rluaf21Mi937BXLJpGKBejqvGtN72rAf6CTWCT9Zfbfj2T+43tY6CpWY Zk9b9CVjb47RLs6E88MX9AdxfLXb7VpSe6b0aelweqXTiA2kwC8pxIdB/ k=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ADAACd1H5glxbLJq1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFAAwEBAQELAYEigX9WATkxjUeIcQOHe5JwgXcFBAcBAQEKA?= =?us-ascii?q?wEBHQEKDAQBAYQMRAKBdSY2Bw4CAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBA?= =?us-ascii?q?QEBAQFohVANhkQBAQEDAQEBbAsFCwsYIAEGBycfEQYTgnEBgmYhD6dxd4E0g?= =?us-ascii?q?QGDQwQMQUSFCwoGgToBgVJihEyGVEOCC4ETJwwQgjAvPoJgAQECAYITgxeCK?= =?us-ascii?q?wSBVBJODGoBAxsUFBBQCwsLbB8mUp1eiyeRY4MWgz+BRoRjkyUEIINPin+Fa?= =?us-ascii?q?ZBLlzCJX5MERwGEAQIEBgUCFoFbAi+BWzMaCBsVOyoBgj4+EhkOVY1jiGuFS?= =?us-ascii?q?z8DLwI2AgYKAQEDCY0PAQE?= IronPort-HdrOrdr: A9a23:1rmxcaroNsZFRLrShRLBsv4aV5qpeYIsi2QD101hICF9WMbwrb HMoN0w0xjohDENHEwxgNzoAsW9aF7V6JId2+gsFJi4Wg2OggGVBaFkqbDv2jjxXxD5n9Q86Y 5Ff7JlANP9SXh25PyW3CCdE9IthOaK67qpg+C29RhQZDpnYa1h8At1YzzzeiZLbTJLCpYjGJ 2X6tAvnUvERV0scs+5CnMZNtKsm/T3kvvdEHw7Li9izAGPiD+ygYSKdySw71M5Ty5Fx6sk/C zjlQH0j5/T1c2T+1v7y3LZ6YhQlZ/a7uZ7QOaIisQTN1zX+2GVWLg= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,237,1613433600"; d="asc'?scan'208,217";a="35229915" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Apr 2021 13:20:58 +0000 Received: from [10.61.144.102] ([10.61.144.102]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 13KDKwNC010276 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Apr 2021 13:20:58 GMT From: Eliot Lear Message-Id: <3767E6D1-7EC1-4163-B099-E68EE1C7FFDD@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_49AA6664-3AE6-442E-A702-A2F2863842E2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 20 Apr 2021 15:20:57 +0200 In-Reply-To: Cc: Bron Gondwana , Ujjwal Sharma , dispatch@ietf.org, Shane Carr To: Eliot Lear References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.102, [10.61.144.102] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 20 Apr 2021 13:21:09 -0000 --Apple-Mail=_49AA6664-3AE6-442E-A702-A2F2863842E2 Content-Type: multipart/alternative; boundary="Apple-Mail=_68351034-5738-4AD8-BF0D-CE46AC991953" --Apple-Mail=_68351034-5738-4AD8-BF0D-CE46AC991953 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just to follow up on this, in case there is any question or if anyone is = keeping score, my question has been answered to my satisfaction and I = support this work proceeding. Eliot > On 14 Apr 2021, at 19:42, Eliot Lear = wrote: >=20 > Signed PGP part > Just one question: >=20 > Is it necessary for both the IETF and TC39 to standardize this? >=20 > Eliot >=20 >> On 14 Apr 2021, at 18:00, Bron Gondwana > wrote: >>=20 >> This was discussed in the DISPATCH meeting at IETF110: = https://datatracker.ietf.org/doc/minutes-110-dispatch/ = >>=20 >> The conclusion of the discussion was: >>=20 >> * Kirsty (chair): Sounds like there's general agreement that a = working group is >> what's needed, we will take a final decision on the list and just = confirm with >> Patrick as co-chair before officially dispatching as such. The link = to the >> charter is on list too, please take a look and see if you think a BoF = is needed >> as the next step or a WG can begin right away. >>=20 >> So Murray (AD), do you think we have enough to request a working = group be charted from the discussion and the proposed charter text = quoted below? >>=20 >> Thanks, >>=20 >> Bron. >>=20 >> On Fri, Feb 19, 2021, at 15:20, Bron Gondwana wrote: >>> I've asked the chairs for space on the next dispatch agenda to talk = about dispatch for >>>=20 >>> https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ = >>>=20 >>> The authors have taken on board the idea that we should extract the = "obsolete RFC3339" and either remove it entirely, or separate it into a = document which does nothing but update RFC3339 with support for a wider = range of year values. There will be an updated version of this draft = soon. >>>=20 >>> The dispatch chairs also asked me for some proposed charter text if = we were to spin up a working group for this topic. Here's that text. >>>=20 >>> Cheers, >>>=20 >>> Bron. >>>=20 >>> Serialising Extended Data About Times and Events (SEDATE) >>> ---- >>>=20 >>> RFC3339 defines a format that can reliably express an instant in = time, either in UTC or in a local time along with the offset against = UTC, however datetime data often has additional context, such as the = timezone or calendar system that was in use when that instant was = recorded. Particularly when using times for interval, recurrence, or = offset calculations, it's necessary to know the context in which the = timepoint exists. >>>=20 >>> It is valuable to have a serialisation format which retains this = context and can reliably round-trip the additional context to systems = which understand it, via intermediate systems which only need to know = about the instant in time. >>>=20 >>> The TC39 working group at ECMA have developed a format which is a = good basis for this work. >>>=20 >>> It is anticipated that this document would be a companion to RFC3339 = rather than a replacement, embedding an un-altered RFC3339 instant along = with the contextual data. >>>=20 >>> It is also within scope for this group to consider a minor update to = RFC3339 to allow larger than 4 digit signed years, to enable = representing times further into the past and future. >>>=20 >>> Once this work is done it is anticipated that this working group = will be short-lived, and once the one or two documents are published the = working group will close down. >>>=20 >>> Milestones: >>> * April 2021: Adopt draft describing a serialisation format for = extended datetimes. >>> * July 2021: Submit the serialisation document to the IESG. >>>=20 >>> -- >>> Bron Gondwana, CEO, Fastmail Pty Ltd >>> brong@fastmailteam.com >>>=20 >>>=20 >>=20 >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch = >=20 --Apple-Mail=_68351034-5738-4AD8-BF0D-CE46AC991953 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = to follow up on this, in case there is any question or if anyone is = keeping score, my question has been answered to my satisfaction and I = support this work proceeding.

Eliot

On 14 Apr 2021, at 19:42, Eliot = Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

Signed PGP part
Just one question:

Is it necessary for both the IETF and TC39 to standardize this?

Eliot

On 14 Apr 2021, at 18:00, Bron Gondwana <brong@fastmailteam.com> wrote:

This was discussed in the DISPATCH = meeting at IETF110: https://datatracker.ietf.org/doc/minutes-110-dispatch/

The conclusion of the discussion = was:

* =
Kirsty (chair): Sounds like there's general agreement that a working =
group is
what's needed, we will take a final decision on the list and just =
confirm with
Patrick as co-chair before officially dispatching as such. The link to =
the
charter is on list too, please take a look and see if you think a BoF is =
needed
as the next step or a WG can begin right away.

So Murray (AD), do you think we have enough to = request a working group be charted from the discussion and the proposed = charter text quoted below?

Thanks,

Bron.

On Fri, Feb 19, 2021, at 15:20, Bron Gondwana = wrote:
I've asked the chairs for space on the next dispatch agenda = to talk about dispatch for

https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-exten= ded/

The authors have taken on board the idea that we should = extract the "obsolete RFC3339" and either remove it entirely, or = separate it into a document which does nothing but update RFC3339 with = support for a wider range of year values.  There will be an updated = version of this draft soon.

The dispatch chairs also asked me for some proposed = charter text if we were to spin up a working group for this topic.  = Here's that text.

Cheers,

Bron.

Serialising Extended Data About Times and Events = (SEDATE)
----

RFC3339 = defines a format that can reliably express an instant in time, either in = UTC or in a local time along with the offset against UTC, however = datetime data often has additional context, such as the timezone or = calendar system that was in use when that instant was recorded. = Particularly when using times for interval, recurrence, or offset = calculations, it's necessary to know the context in which the timepoint = exists.

It is = valuable to have a serialisation format which retains this context and = can reliably round-trip the additional context to systems which = understand it, via intermediate systems which only need to know about = the instant in time.

The TC39 = working group at ECMA have developed a format which is a good basis for = this work.

It is = anticipated that this document would be a companion to RFC3339 rather = than a replacement, embedding an un-altered RFC3339 instant along with = the contextual data.

It is = also within scope for this group to consider a minor update to RFC3339 = to allow larger than 4 digit signed years, to enable representing times = further into the past and future.

Once this = work is done it is anticipated that this working group will be = short-lived, and once the one or two documents are published the working = group will close down.

Milestones:
* April = 2021: Adopt draft describing a serialisation format for extended = datetimes.
* July 2021: Submit the serialisation = document to the IESG.

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



--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


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


=
= --Apple-Mail=_68351034-5738-4AD8-BF0D-CE46AC991953-- --Apple-Mail=_49AA6664-3AE6-442E-A702-A2F2863842E2 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmB+1TkACgkQh7ZrRtnS ejPJKAgAgEVSscwTARZxsAN8Yz98xZMVgW5w2POWYoJNkqYIAJtol9ReS45J1JZ5 gEeR2eQuRVEIxgC5RSg01ffD8+xu7pYE3bAIp61uzXBdyKwbgZ3qdEXJHMLGvKUF 3DHjcphZLhM6xgjXi7X3wd4x2k++PJYe5Rd0+ikyfhFw1c6koq6LLK7S5IkhmzCJ slwngrEHQAwXPmNNHXrULCOlRgM8f6OWJk1uxFzhIXe9IkwD0xvHXcYkGS5rjCkA r+Jyd5zFWYXOzvI5HqFkY36LC+P1zXSlFulKcUPgtqVlHCYs3CDJrX5LkXH4u1JQ ZlLs/VrCDTv06S3pZ+adzaKFMmCLig== =6FBP -----END PGP SIGNATURE----- --Apple-Mail=_49AA6664-3AE6-442E-A702-A2F2863842E2-- From nobody Tue Apr 20 09:14:05 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06C33A2872 for ; Tue, 20 Apr 2021 08:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=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 vzTU082qZjZT for ; Tue, 20 Apr 2021 08:40:10 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 002CC3A2871 for ; Tue, 20 Apr 2021 08:40:09 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id r186so11558689oif.8 for ; Tue, 20 Apr 2021 08:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M16IgzLbMOgpuldFx4E4rCRKv70fQmpT2vzNikv34fw=; b=o8AJ6KwBnriYvNf1XPK/5g2K1PSZG01k9GxOPfxKNckwWJfgK3oQi5RfyOPav0dgFE WVERrpy7meEW+95tiK08v+x7HADKVI8F48+wH//QIGzmux7wRlZISNPi4NOMmSjMv2De VzdPM0qXKRDDobNeGHBmVLwTcI2W+B+DVPBbsEW4cHYdL1dH8v8c1gpyGCp7sBCyP737 Jx4Z8nnscjescq1dEYUYdfYrVvYy92xtEhS7jqZGOJidFi976f2MXIoY3epdbzXAliRk UT2bdaDN5/X1iRXnb8OMNpmVek0xkcII1xAueaLnDJFesaytJvnnRQ55/Ik9r2U5pNuT a4mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M16IgzLbMOgpuldFx4E4rCRKv70fQmpT2vzNikv34fw=; b=K9n9WBDGEtL9H8ZCfcDQdk/Lts/pDOiYu3+Z+Jjl690U4COXrGlSEIXk0sCPqeWN+D xOM9zDTDuE0118ga4Z5saIWQqJntqpBBMyw3O87at9je9gIJfPm+LhPjHZo+jOJimMGh p7Ma9enNu7zryjmnoAsvrZAnh1UQiqGcPb8gQ9P6QV0z2Q74/BgcX9leBBTiuA+QXdfS FJXMLSkrt1e5g72wTlistS8S0ivApLSmhnSXhd1zkIIpXvbYWDDOenwBDja1QFE8Lki4 MH8WeEHkPuqMoBeOf4NASt+XeV1orWsfWjeo+XXEhZdveg8xet3Hk9MGtg1t3N6e+jhK NwwA== X-Gm-Message-State: AOAM531kPF0/FvZPivauayIqBOlqVPKjfqAPedbS5xyf06iGaAULNDmM aazSuXRDN5vks3l4C+I0xJibeMYa1UgYYSWd/0CaVA== X-Google-Smtp-Source: ABdhPJyNoyROoAv3sVbdFdMOrbJl3aLD1EH2BTAktiLSh5j6ACmssjwiopGeGat5DfYDyceIxo8MtuVA4OnBWVg/EQ0= X-Received: by 2002:aca:c3cf:: with SMTP id t198mr3671874oif.179.1618933208290; Tue, 20 Apr 2021 08:40:08 -0700 (PDT) MIME-Version: 1.0 References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> <3767E6D1-7EC1-4163-B099-E68EE1C7FFDD@cisco.com> In-Reply-To: <3767E6D1-7EC1-4163-B099-E68EE1C7FFDD@cisco.com> From: Shane Carr Date: Tue, 20 Apr 2021 10:39:56 -0500 Message-ID: To: Eliot Lear Cc: Eliot Lear , Bron Gondwana , Ujjwal Sharma , dispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000cbe49505c0694265" Archived-At: X-Mailman-Approved-At: Tue, 20 Apr 2021 09:14:03 -0700 Subject: Re: [dispatch] Proposed charter for extended date format 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, 20 Apr 2021 15:40:16 -0000 --000000000000cbe49505c0694265 Content-Type: text/plain; charset="UTF-8" I am looking forward to seeing the charter for this WG adopted, so that we can work on the substantive issues in that forum. What are the next steps to adopt the charter? On Tue, Apr 20, 2021 at 8:21 AM Eliot Lear wrote: > Just to follow up on this, in case there is any question or if anyone is > keeping score, my question has been answered to my satisfaction and I > support this work proceeding. > > Eliot > > On 14 Apr 2021, at 19:42, Eliot Lear > wrote: > > Signed PGP part > Just one question: > > Is it necessary for *both* the IETF and TC39 to standardize this? > > Eliot > > On 14 Apr 2021, at 18:00, Bron Gondwana wrote: > > This was discussed in the DISPATCH meeting at IETF110: > https://datatracker.ietf.org/doc/minutes-110-dispatch/ > > The conclusion of the discussion was: > > * Kirsty (chair): Sounds like there's general agreement that a working group is > what's needed, we will take a final decision on the list and just confirm with > Patrick as co-chair before officially dispatching as such. The link to the > charter is on list too, please take a look and see if you think a BoF is needed > as the next step or a WG can begin right away. > > > So Murray (AD), do you think we have enough to request a working group be > charted from the discussion and the proposed charter text quoted below? > > Thanks, > > Bron. > > On Fri, Feb 19, 2021, at 15:20, Bron Gondwana wrote: > > I've asked the chairs for space on the next dispatch agenda to talk about > dispatch for > > https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ > > The authors have taken on board the idea that we should extract the > "obsolete RFC3339" and either remove it entirely, or separate it into a > document which does nothing but update RFC3339 with support for a wider > range of year values. There will be an updated version of this draft soon. > > The dispatch chairs also asked me for some proposed charter text if we > were to spin up a working group for this topic. Here's that text. > > Cheers, > > Bron. > > Serialising Extended Data About Times and Events (SEDATE) > ---- > > RFC3339 defines a format that can reliably express an instant in time, > either in UTC or in a local time along with the offset against UTC, however > datetime data often has additional context, such as the timezone or > calendar system that was in use when that instant was recorded. > Particularly when using times for interval, recurrence, or offset > calculations, it's necessary to know the context in which the timepoint > exists. > > It is valuable to have a serialisation format which retains this context > and can reliably round-trip the additional context to systems which > understand it, via intermediate systems which only need to know about the > instant in time. > > The TC39 working group at ECMA have developed a format which is a good > basis for this work. > > It is anticipated that this document would be a companion to RFC3339 > rather than a replacement, embedding an un-altered RFC3339 instant along > with the contextual data. > > It is also within scope for this group to consider a minor update to > RFC3339 to allow larger than 4 digit signed years, to enable representing > times further into the past and future. > > Once this work is done it is anticipated that this working group will be > short-lived, and once the one or two documents are published the working > group will close down. > > Milestones: > * April 2021: Adopt draft describing a serialisation format for extended > datetimes. > * July 2021: Submit the serialisation document to the IESG. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > --000000000000cbe49505c0694265 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am looking forward to seeing the charter for this WG ado= pted, so that we can work on the substantive issues in that forum.=C2=A0 Wh= at are the next steps to adopt the charter?


On Tue, Apr 20, 2= 021 at 8:21 AM Eliot Lear <lear@cisco.= com> wrote:
Just to follow up on this, in = case there is any question or if anyone is keeping score, my question has b= een answered to my satisfaction and I support this work proceeding.
Eliot

On 14 Apr 2021= , at 19:42, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:
Signed PGP part
Just one question:

Is it necessary fo= r both the IETF and TC39 to standardize this?

Eliot

On 14 Apr 2021, at 18:0= 0, Bron Gondwana <brong@fastmailteam.com> wrote:

= This was discussed in the DISPATCH meeting at IETF110:=C2=A0https://datatracker.ietf.org/doc/minutes-110-dispatch/

The conclusion of the discussi= on was:

* Kirsty (chair): Sounds like there's general a=
greement that a working group is
what's needed, we will take a final decision on the list and just confi=
rm with
Patrick as co-chair before officially dispatching as such. The link to the
charter is on list too, please take a look and see if you think a BoF is ne=
eded
as the next step or a WG can begin right away.
So Murray (AD), do you think we have enough to req= uest a working group be charted from the discussion and the proposed charte= r text quoted below?

T= hanks,

Bron.
=

On Fri, Feb 19, 2021, at 15= :20, Bron Gondwana wrote:
I&#= 39;ve asked the chairs for space on the next dispatch agenda to talk about = dispatch for


The authors have taken= on board the idea that we should extract the "obsolete RFC3339" = and either remove it entirely, or separate it into a document which does no= thing but update RFC3339 with support for a wider range of year values.=C2= =A0 There will be an updated version of this draft soon.

The disp= atch chairs also asked me for some proposed charter text if we were to spin= up a working group for this topic.=C2=A0 Here's that text.

C= heers,

Bron.<= br>

Serialising Extended Data About Times and Events (SEDATE)<= /span>
--= --
=
RFC3339 defines a format that c= an reliably express an instant in time, either in UTC or in a local time al= ong with the offset against UTC, however datetime data often has additional= context, such as the timezone or calendar system that was in use when that= instant was recorded. Particularly when using times for interval, recurren= ce, or offset calculations, it's necessary to know the context in which= the timepoint exists.

It= is valuable to have a serialisation format which retains this context and = can reliably round-trip the additional context to systems which understand = it, via intermediate systems which only need to know about the instant in t= ime.

The TC39 working gro= up at ECMA have developed a format which is a good basis for this work.
=
It is anticipated that this = document would be a companion to RFC3339 rather than a replacement, embeddi= ng an un-altered RFC3339 instant along with the contextual data.

=
It is also within scope for this gr= oup to consider a minor update to RFC3339 to allow larger than 4 digit sign= ed years, to enable representing times further into the past and future.

Once this work is done it i= s anticipated that this working group will be short-lived, and once the one= or two documents are published the working group will close down.
Milestones:<= span>
* April 2021: Adopt dr= aft describing a serialisation format for extended datetimes.=
* July 2021: Submit th= e serialisation document to the IESG.

--
=C2=A0 Bron Gondwana, CEO, Fastmail Pt= y Ltd

=


--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty L= td


_______________________________________________
dispatch mailing li= st
dispatch@ietf.org
https://www.ietf.org/mailman/list= info/dispatch


<= /div>

--000000000000cbe49505c0694265-- From nobody Mon Apr 26 08:26:12 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071DF3A253E for ; Mon, 26 Apr 2021 08:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzML6M9gTetk for ; Mon, 26 Apr 2021 08:26:06 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100101.outbound.protection.outlook.com [40.107.10.101]) (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 6A4223A260A for ; Mon, 26 Apr 2021 08:25:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kCvlAH4BvbubljzCnhoUIkIvXD6HFQE/VXMOBPAheewJu2SnScF1S80fNnlZ4E00UfKjambt35b6oagyLxi+g5KnSYa8XWnXNmp/ik8wtFCWDLmtKLE7zSytItO3ow4aUzgNictgl4PJC52EZFbaPJ/l0iiGpbzuyze6ivw3qKewwV6/C0vJnPt1eWJE3BQDDSycidkb+lunH6DuAA9iQ79uVGDw6YSFIKmm4wfqypHIx1pON39Bvluz3oZPa0ISdLUCw7nFTwRZ9Xy8p049b3/UxjHWUbSia/8c0UbNJ642WkobLYUrtz/9uK+rrnoBh5COjbcTnennN94EiZ78Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0sSS16IThjyRCDWOjx5XE0JI0b7Sz7elanq0D8M9tc=; b=kyhEvwuzdsHSLWIjwSnVwHWKa/2IJ8yisHHWzQkaDQ6RUJSfL0PgxFU62SgW2Wei+lLR/LESxCnY8SziTuJcs0ppOmWUxIR1xQurXnCV4Y/Fgz6i1dvyV0gDIsSTnzNop/TZo3+Nzisq5+rYeb4wAnjlM3O9rNLv3dG/RnRBZcMlJPRny7DV7I4HwEtTBV8db5WkEEhsGKNfi5VtfrHAn823gErY27hfeLud1XTo6JYpopPMhaDL14opjL1gymDaW4ZmesAoUmkX4+H4glt8saxy0shblIr8xePZQ502/7VjX7mjMQQINSgW35CDYuaKAxzXTcs0Sj7VTy0S8wlQjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0sSS16IThjyRCDWOjx5XE0JI0b7Sz7elanq0D8M9tc=; b=HSOiNUm3DCK2OXK89UINRUL+1mehPoWQf4FGHfkIIcoExYATR56SSZjkvs5B5msw5jq1PVqhNaDcR5gJUxtdU6HW8Gs21Eo0UyoI8v1EBnstWRxZe3eEHw4mXfmivgRCrXqo1hbA+7sYZzsI+CtgL/3a4Mvl/SVKC17glJ/tu1zC4iPYbfHa6eQe0O9zRuEEMBWxXIrDyJRH0+p24XRnsKJA1R7Dmdk1OwVhc7eUYNlypau1FDYE/LO+0ycIAfDmXd1GYSEecloLIRlq1jFw7Xu6bta+JPp/+WvNq0/s1EzoJQ3uInbB2cIDmzUWBCTG7OK2xhImb8xFFbRNLoPLxw== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO3P123MB3257.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:fc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Mon, 26 Apr 2021 15:25:48 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::d1dd:5a6f:a08e:6b23]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::d1dd:5a6f:a08e:6b23%7]) with mapi id 15.20.4065.027; Mon, 26 Apr 2021 15:25:48 +0000 From: Kirsty P To: "dispatch@ietf.org" Thread-Topic: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May Thread-Index: AQHXOqhcB1bTUOeuTkGh5n4uByJr4g== Date: Mon, 26 Apr 2021 15:25:47 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-originating-ip: [51.132.68.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e42e6c3f-bd07-424f-f3d3-08d908c79163 x-ms-traffictypediagnostic: LO3P123MB3257: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4eU0NyHyPYQB86k2NcLQF1q7bWUzha/ANjku912IAkhPe+SW6JvxvKzSZIVHkxEL9vMLDcNDjg42K3UfgK8nMoR1yHbKryJkR4/bqjes4qF1FuBZG+JmpkC82LjQWJHukPzLgR9z+lVZ+y1ayUCJGPiQ5tIOhQtpGuRheW5EWkwUAGR4RAOpuBmvqAlRTDcZF1H82sy4DvLQD2sIEIA0clg8pjNU1jAwXvELj8IoUK6jaVGC5+lU6M1DeV0m8/nch3XlU5WtH5zhluxEBSr8uFpCicM3txnEk4BgWjo2yZ0M5VTmAw10LKzunJuFLjZZy2IL8GBlvXg/5CCQo3Q4KUXxtzf0Al7FVw6MooMCx+hMHPG4PlEkL71EM98sIFR2YA32d7vmH0dIm2utQGTzXWG693nLrBk9elkL70AyVCO1/9N56WIlu+RilwW6b8ZVwVjg2xE2cczw24Yo0Q/xZMxFqhHyReY3ifKHHTsPiOL29fLc8h50Dd5L8LzgMwud1pH5B0DjYEViS/LNKeWfR0we3iyqnhprIEnmv4YMh6WNpfynTHnUBOgCi8FhaBE+krd5X1FGjB/VJeYJ+ICtqC4IKIYZLlCskXQILFMtGsVJCvsGZ3JxReUAvse5xsJWV4H79PrzwcmE6icbbG/l7deg0ozCGl2RigLCXXVT5yc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(396003)(346002)(376002)(366004)(136003)(86362001)(83380400001)(122000001)(316002)(52536014)(38100700002)(19627405001)(8936002)(5660300002)(2906002)(186003)(478600001)(6506007)(26005)(8676002)(66446008)(71200400001)(66946007)(76116006)(66476007)(55016002)(33656002)(66556008)(64756008)(6916009)(9686003)(966005)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?rKQy8V22ODxQ2TiVAbIdfT85pP7g6xZx/eTVMuy6h14Sne8QiZu9jOq8Vd?= =?iso-8859-1?Q?e8lZt3jbu2mlyWeEO0VwltfvFTAQ4zyLeRX05iT+TbJndLUHYUkR/RrVjN?= =?iso-8859-1?Q?dsMpth2WNl3GF/Pj/wpmCeqJgGHtKYwGpI8rCcdAcmNVYw5pHK6ETb6aCr?= =?iso-8859-1?Q?Bhd3+EhhKV3RU2XqRxCef9h4Nl+JntFJuicWeauLo4edFtwUMFPeRhTKMz?= =?iso-8859-1?Q?jRRBnzKpBzx8OAJdB7xTdNSB8bmvElTMRiI1r47HH1LFFTJttTYe1hz94z?= =?iso-8859-1?Q?V0ePGwp/Be96f8g1YsFSA6b5Hegp9wz/5onFHrO/WXmhdnoLx+wCfQjKvB?= =?iso-8859-1?Q?JnscHaKgP5Dvqqc+dcq3fxRcA+dzazKOh4bby9lfGCwmlPtQhwntf2LrPR?= =?iso-8859-1?Q?6qWhKuEQzzQ0KkqIzOTrSFLodmULWu+b22dqmrcrUB0a4ExsTiyWbJY/cK?= =?iso-8859-1?Q?cUBw5VhuzyZNj3xcDxZ+MNgdAQnXLtsD59shXnQZNJdgVuAUZFldrBQCnU?= =?iso-8859-1?Q?YXZK090VHsav7KqtKjjA7ppKU5f8SNj6xa6Iu65Js++Rn8avO5mAkL84Jn?= =?iso-8859-1?Q?dSzHroFGvsC5/UDNl3Y6wTsvYj0Rv4YHvcqZfaDLZbLDSCcMpNw6NVBSmV?= =?iso-8859-1?Q?1JPVSL9mktghS6hEsCF5R7ur99eFYF8VwK60MWDqqxQ77WKsUKvfPLLBRd?= =?iso-8859-1?Q?b1rZSH85+BMHCR6uS5bdOmMl5z2/xjNH14C1Do4G81P4+g2waISHTcWmgc?= =?iso-8859-1?Q?6lStprMjxOszIs5tJCiu9cMc0MJF48tMFHJtlOrXlqMniUgSnRojyKNXYz?= =?iso-8859-1?Q?3l78hw4i6VrQJ/P5Pg3r3QYwuLxmLuCrkRZTiHqJfCSFTwT5pkLQRZ9thx?= =?iso-8859-1?Q?4EHhZV0z0dDOrnlxksbJ+twZ9hloAv1vabqsjhRMbaKbKD8a9lEZDxZTn5?= =?iso-8859-1?Q?TskLdcTApMIzgvrZIjwwOya+G0TvLBjA10z80U3AWuUudV+v0/UWpzTajC?= =?iso-8859-1?Q?CK7gXdNsT1Tt6VQL63ElbfYp8W0siH+CCeuxz8kyR+yuoq7Cr5JeZrQ7sw?= =?iso-8859-1?Q?knldnnLX54vvilH2HuTW1mAXi6HswidxIGk+GqTbx7km8JRilo0hPpwwTh?= =?iso-8859-1?Q?TsswGvhcEr3CTHx8FNJOuQNfIQay+4JaQ077qsl2i5r4a0otBr9dLkv+sN?= =?iso-8859-1?Q?mu+JNGGKVnsMlpUfyb5WtRgI1ofFZVDEZ0hOzHInUub9+SkIB/ydqRPLcf?= =?iso-8859-1?Q?oohsstFaJtwyzf8w97V4RAoWjP7OcI0a4WZMMt1sRjE/LEhPkZTjcFfQF2?= =?iso-8859-1?Q?DmiwYyEVJJODJcte/rVVjtfPEN+CqNc07EC8Wrr7hTDtw7XvchS9Wj5co3?= =?iso-8859-1?Q?UTX6T5NW5Q?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB3599980BA2B5A5ACA59ECF6FD7429LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e42e6c3f-bd07-424f-f3d3-08d908c79163 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2021 15:25:47.9640 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0Ot5TrDjO7jncAhmWt+Amf33yMHmQMgRIjyLj7Ege/SBkq2HDiYNosMKDw/+GyRwz9K2hh36PyMC8PavVQbX9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO3P123MB3257 Archived-At: Subject: [dispatch] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 15:26:11 -0000 --_000_LO2P123MB3599980BA2B5A5ACA59ECF6FD7429LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi DISPATCH, Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd WGLC (= Working Group Last Call). Please send your comments and/or expressions of s= upport to the DISPATCH list. Longer: the draft was recently updated to address feedback from a review an= d from the 2nd WGLC [1]. The authors posted an update to the list with more= information [2]. We (DISPATCH chairs) feel like all the comments have been= addressed, so it's time for 3rd WGLC. We need to hear positive noises and support for this draft from the WG befo= re progressing the -08 draft, so please email to signal your endorsement, e= ven if you have no comments to make. The draft can be found on datatracker = here: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ WGLC is open for 2 weeks - so will finish close-of-play on Monday 10th May. Kirsty (DISPATCH co-chair) [1] https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUq= Xg0/ [2] https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mz= kis/ This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599980BA2B5A5ACA59ECF6FD7429LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi DISPATCH,

Summary: draft-ietf-dispatch-javascript-mjs is now ready = for its 3rd WGLC (Working Group Last Call). Please send your comments and/o= r expressions of support to the DISPATCH list.

Longer: the draft was recently updated to = address feedback from a review and from the 2nd WGLC [1]. The authors poste= d an update to the list with more information [2]. We (DISPATCH chairs) feel like all the comments have been addressed, so it's = time for 3rd WGLC.

We need to hear positive noises and support for this draft from the W= G before progressing the -08 draft, so please email to signal your endorsem= ent, even if you have no comments to make. The draft can be found on datatracker here: https://d= atatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

WGLC is open for 2 weeks - so will finish close-of-play on Monday 1= 0th May.

Kirsty
(DISPATCH co-chair)

[1] https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoF= gxBUqXg0/
[2] https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mz= kis/



This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599980BA2B5A5ACA59ECF6FD7429LO2P123MB3599GBRP_-- From nobody Mon Apr 26 12:11:50 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7123A2369 for ; Mon, 26 Apr 2021 12:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-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=igalia.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 BazRHvf_ZE1f for ; Mon, 26 Apr 2021 12:11:44 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 661AF3A2361 for ; Mon, 26 Apr 2021 12:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=byiFHsJ3bvCp8PXXQYo7ZJ05MAbp/z46V7iIVm1Crww=; b=WbKCbZphGnRihcup4aJl8HNCUW13O8lX4vWeLGEPi7m2bh8l36g6JjZVghJ/l7yPwtLffpD9CgQelvmOjdhbsK6rPHdM5H82wNjlpaAd7Y3YPyU3SEYsvEgAibiS6pEwg3450/1NoYbiRvYB8ruCsQrE/XhjxJ5p9Eq1iX6Vp/7nThIHbnlminykPQCiEPAX0ccSVQEt+9K08b5jmt1G6tCiwuX6rBl5sK5sWMAF8OmsCGfumqfk77fZ8dqKZQj0HdP8PUneUhS9H9sNVJ2tm8srNyeP8nCEzw5c276Qk5+olNhGQjJvjXi2peFGjDqDTNqKJhIuc7RGYXK41VtmFA==; Received: from [183.83.214.160] (helo=[192.168.0.190]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1lb6du-00027S-9q for ; Mon, 26 Apr 2021 21:11:38 +0200 To: dispatch@ietf.org References: From: Ujjwal Sharma Organization: Igalia S.L. Message-ID: Date: Tue, 27 Apr 2021 00:41:26 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 19:11:50 -0000 Hello everyone! As someone who has been closely following this on the ECMAScript side, I strongly support this. Big thanks to everyone involved! Ujjwal On 26/04/2021 20.55, Kirsty P wrote: > Hi DISPATCH, > > Summary: draft-ietf-dispatch-javascript-mjsis now ready for its 3rd > WGLC (Working Group Last Call). Please send your comments and/or > expressions of support to the DISPATCH list. > > Longer: the draft was recently updated to address feedback from a review > and from the 2nd WGLC [1]. The authors posted an update to the list with > more information[2].We (DISPATCH chairs) feel like all the comments > have been addressed, so it's time for 3rd WGLC. > > We need to hear positive noises and support for this draft from the WG > before progressing the -08 draft, so please email to signal your > endorsement, even if you have no comments to make. The draft can be > foundon datatracker here: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > WGLC is open for 2 weeks - so will finish close-of-play on Monday 10th May. > > Kirsty > (DISPATCH co-chair) > > [1]https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg0/ > [2] > https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzkis/ > > > > This information is exempt under the Freedom of Information Act 2000 > (FOIA) and may be exempt under other UK information legislation. Refer > any FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown > Copyright > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker From nobody Tue Apr 27 07:17:35 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9473A0B60 for ; Tue, 27 Apr 2021 07:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.1 X-Spam-Level: X-Spam-Status: No, score=-17.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, 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 whMzLNHuNoow for ; Tue, 27 Apr 2021 07:17:29 -0700 (PDT) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 804FB3A0B5A for ; Tue, 27 Apr 2021 07:17:29 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id z1so69506444ybf.6 for ; Tue, 27 Apr 2021 07:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iRNRke4NaBdNYKcygXzYlQlhNtAsbhNijuvOieYzCxc=; b=Wm7juxcsiawvrH2p+dUfE35tZqgBJtFwU2hCBIRY03uGanLgM5V4mE/nO4HcPHJeIQ D9kVt2ZN0UHpO/EAb/hWUITcf/h33L+5LLg65zayDlI5ixYx2dJR7MzQkno/UpDRGbIe eqHHOMR1MVLMIk3CQEiLL+Gi/GFXwEzx2P73vDuNoaT6ZVm06JjvKfVAaoaozozkycjg xMQuje9j00gVW+Dqpdnmd9LgDw/GI8FOm0RNGM62dFK2+f5toPqhxrDVHUunCfFPL60g zLCqEWIWVLmwyWfJqzW5ThJoRA5OBcrirvnAAgfSHgyA7DTkyDXENxXgLDtC2yNCKKHU etXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iRNRke4NaBdNYKcygXzYlQlhNtAsbhNijuvOieYzCxc=; b=ucI3AR2PjsXUTIlmlm/s6Qhvf7Qp6SHFLQ6CmbQBG/+AwhfQnvdnIBO3onX9t7ufoM 0+eO+Q24KVr0oE/hAHV3Pl4uRhm9MRKGVj5E5I+OQGEBFmr+1Lu4uBFDJhw8VXqNPheX AxbJ03zk+iUrNPyneCJ9LBVIgRIhOKRoHjUpa7qfM7AvC98U9LooR+Hsi66C5IRDE4uc xrOdyzVtTnoM52m8ly4P9JWOuyDONsZxrlcVy1TywDfF5TDwhkedDuJRXxVrK0hyiBFn QGwu59i8UXmt3yKAgek+UEV9iyYcQNFU7B/WJw7fb+zHy0S71d2oo66LFWUKHXnB09vX DF4Q== X-Gm-Message-State: AOAM5334XbCEH58NAlLHdoIylGsnm8/34+NEoGP8Z6v6ATbQm+I5fx8g qQQunyRCdA2bCD84wb6ZdrIFrzAWKBL4jmTxwrmb7w== X-Google-Smtp-Source: ABdhPJw7unYeo4HsPGGCNmRlGH3L1KlakE/ifwbysFXicvx9WiMjUe2S5GyiD62gmJKrcwZoTgtJJsQEZkjfQP/QPQ4= X-Received: by 2002:a25:9c86:: with SMTP id y6mr1839065ybo.405.1619533046835; Tue, 27 Apr 2021 07:17:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mathias Bynens Date: Tue, 27 Apr 2021 16:17:16 +0200 Message-ID: To: Kirsty P Cc: Myles Borins , "Matthew A. Miller" , DISPATCH WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 14:17:34 -0000 Disclaimer: I am one of the authors of this draft. Nevertheless, I would like to express my support and speak to the importance of its standardization. The draft supersedes the earlier RFC4329, providing updated definitions to align with what has quickly become implementation reality, both in web browsers as well as other popular JavaScript environments such as Node.js. Thanks, Mathias On Tue, Apr 27, 2021 at 3:49 PM Kirsty P wrote: > ________________________________ > From: Kirsty P > Sent: 26 April 2021 16:25 > To: dispatch@ietf.org > Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th Ma= y > > Hi DISPATCH, > > Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd WGLC= (Working Group Last Call). Please send your comments and/or expressions of= support to the DISPATCH list. > > Longer: the draft was recently updated to address feedback from a review = and from the 2nd WGLC [1]. The authors posted an update to the list with mo= re information [2]. We (DISPATCH chairs) feel like all the comments have be= en addressed, so it's time for 3rd WGLC. > > We need to hear positive noises and support for this draft from the WG be= fore progressing the -08 draft, so please email to signal your endorsement,= even if you have no comments to make. The draft can be found on datatracke= r here: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs= / > > WGLC is open for 2 weeks - so will finish close-of-play on Monday 10th Ma= y. > > Kirsty > (DISPATCH co-chair) > > [1] https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxB= UqXg0/ > [2] https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5= Mzkis/ > > > > This information is exempt under the Freedom of Information Act 2000 (FOI= A) and may be exempt under other UK information legislation. Refer any FOIA= queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =C2= =A9 From nobody Tue Apr 27 08:27:41 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639AE3A10C7; Tue, 27 Apr 2021 08:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5ebtYXOGOPk; Tue, 27 Apr 2021 08:27:35 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 D3FB23A10C5; Tue, 27 Apr 2021 08:27:31 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id n21so13883423eji.1; Tue, 27 Apr 2021 08:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Su1b6AwVPUEry3M5HdAShW9WgyxwpjHbHuDsX3YB7cQ=; b=PBQ2CvrhAgd00SDMM4iHGX8qGmkPPvZyX0vpr27/4RXmywQjVFmzWG/zZsBLJ5C/N5 92P2rEmX5KG4hs8bxzzm9cKgac0cHQgst3WPI5Jt2RGs9GsUtW2c3dPp3UOKgEkEy50f IH2x6GsPsH1cqufXlHD24FfnGiYXVsEK8wLt+e417ShtFgDDKy0Z+H3OVi3UxTwt5l5t yJG2stdJqUvry3CJH94LjN8m0/BK4y6vKD8o6X0Ilqwo59/SuZNP70ARoULpzOkcMkHF t/j8KId0Ee1nKq1PhHlOXFLRwni+gKWFEb42xjAIhJufNGqZFRG5KkdtVCDoL0kbu4AR B6Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Su1b6AwVPUEry3M5HdAShW9WgyxwpjHbHuDsX3YB7cQ=; b=f/5cp22hEtibt2nt8RvZuaDaY/NmhmSXQrNLL1FW9GkNBjCA8N+0CHy8IcK6c9Me+a kFrekVzEtYAMTp5Swr7IADgkGbz5OiU66lZKKJiN7Nn9d9M3CywuFkEoZqmCMiV3aiq3 plWXYoU26K8NmoSwZRbXm4r64Ew8ENjUZzQns9M/yzsyz9wnb82A1BBn3rG5NiWlLjYt TULuiOKGWBoVKNL/pO/7zKipxtaN5t4oANMwO4ufmuCsIZGaML1rtAP9gdzI+5PygoCw kg5dS1MAPNNydK2GuE8ghPlSF7Dy1jzSj8HjD6cLsZhlFSfXx2BV1l4gPwSXcNi6SAfU GO9Q== X-Gm-Message-State: AOAM533H8pr5oj7NqXwcm8vetuIpvZaa/tQvuMEXYCmoY/XkwbYmir2a byx8mTuUCgEzgxsT4P4c+Ys6dvx4m01MvUCtdhthehniD/I= X-Google-Smtp-Source: ABdhPJwSomPkLTIMvp4E5sxZtS7tV4/7MLzSfCOlP+u/GZIcDkxk92mqCa8CuF966qIk1IUNEV8O57O2BrMy16N5w7A= X-Received: by 2002:a17:906:c290:: with SMTP id r16mr23952010ejz.241.1619537248667; Tue, 27 Apr 2021 08:27:28 -0700 (PDT) MIME-Version: 1.0 From: Bret Jordan Date: Tue, 27 Apr 2021 09:27:17 -0600 Message-ID: To: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org Content-Type: multipart/alternative; boundary="000000000000684d2105c0f5e645" Archived-At: Subject: [dispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 15:27:39 -0000 --000000000000684d2105c0f5e645 Content-Type: text/plain; charset="UTF-8" Dear Dispatch, Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for your consideration. This document describes how to use JWS and JCS to create plain-text JSON signatures. The abstract reads as follows: This document describes a method for extending the scope of the JSON Web Signature (JWS) standard, called JWS/CT. By combining the detached mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing). In addition to supporting a consistent data format, this arrangement also simplifies documentation, debugging, and logging. The ability to embed signed JSON objects in other JSON objects, makes the use of counter-signatures straightforward. The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ As you know there are large ecosystems that needs digital signatures for plain text JSON data, meaning where the JSON data is not base64 encoded. This ID provides a solution using existing IETF RFCs to make this work. Further, this work looks to be adopted by many groups and organizations from financial services, threat intelligence, and incident response. We are not sure what direction would be best for this work in the IETF, should we send to the ISE for publication or do you want to create a working group. Ultimately there is a lot of work that could be done in this space to meet the needs of the market. We would be happy with releasing these IDs for ISE publication, or for creating a working group to move them forward. It is just important to note that the market is in desperate need of these solutions. If you want to take it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct Thanks Bret -- Sent from my TI-99/4A PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 --000000000000684d2105c0f5e645 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Dispatch,

Anders Rundgren, Samuel, Erdtman, an= d I have been working on an ID for your consideration. This document descri= bes how to use JWS and JCS to create plain-text JSON signatures. The abstra= ct reads as follows:

This document describes a method for extending = the scope of the JSON Web Signature (JWS) standard, called JWS/CT.=C2=A0 By= combining the detached mode of JWS with the JSON Canonicalization Scheme (= JCS), JWS/CT enables JSON objects to remain in the JSON format after being = signed (aka "Clear Text" signing).=C2=A0 In addition to supportin= g a consistent data format, this arrangement also simplifies documentation,= debugging, and logging.=C2=A0 The ability to embed signed JSON objects in = other JSON objects, makes the use of counter-signatures straightforward.
The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-j= ws-ct/

As you know there are large ecosystems that needs digital= signatures for plain text JSON data, meaning where the JSON data is not ba= se64 encoded. This ID provides a solution using existing IETF RFCs to make = this work. Further, this work looks to be adopted by many groups and organi= zations from financial services, threat intelligence, and incident response= .

We are not sure what direction would be best for this work in the= IETF, should we send to the ISE for publication or do you want to create a= working group. Ultimately there is a lot of work that could be done in thi= s space to meet the needs of the market. We would be happy with releasing t= hese IDs for ISE publication, or for creating a working group to move them = forward. It is just important to note that the market is in desperate need = of these solutions. If you want to take it for a spin, there is a JWS/CT pl= ayground at: https://mobilepki.org= /jws-ct

Thanks
Bret
=
--

Sent from my TI-99/4A

PGP Fing= erprint:=C2=A063B4 FC53 680A= 6B7D 1447 =C2=A0F2C0 74F8 ACAE=C2=A07415 0050
--000000000000684d2105c0f5e645-- From nobody Tue Apr 27 08:47:21 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492AB3A11E3 for ; Tue, 27 Apr 2021 08:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI58G1bsBabN for ; Tue, 27 Apr 2021 08:47:13 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 E260C3A11E0 for ; Tue, 27 Apr 2021 08:47:12 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id z25so21725223qtn.8 for ; Tue, 27 Apr 2021 08:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=52erJvHyH211Q+bUlVrzfZOPr8C/5MWHC+YGVbtO83o=; b=1q9NPBKHdjC12o5GTxJOs75Q202SY+VF8VG5aPFA2zlGuCF+C8iRwoq791cwlx/Cau fDDZ7zrImFABE5jyJC3fhGXLm3Oexi14gTqiZkTbju4i/IWH0axNDel0Qna1W3TGzC2R Dzi+4OuAn+DO84LnxoyzEab6jCGzP/ziDn2aEmYDp2vp7TW37vJC9owAm/gLiJb34cAm A7O3a0FAU+pQnabtdhSSa80bsDQ9F6sFx4Y/hq+Hbwxm2mPXuhn5V0dV4V+TRygti4GG /A4PQvXaeHph+9ULR2mrWRpoD612qFrd3y29OFR81b7AGrojZVBqQ1iCzD1zlsE+8sQd tdvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=52erJvHyH211Q+bUlVrzfZOPr8C/5MWHC+YGVbtO83o=; b=O10yrlVo/JoiYCzDe9OoByJW80E9Rye8IzFA4plIbxcQbn+jUzCr4r+S+bGOMlIog9 V2skp44gniZFOXz7xGycznwwkiNNdKxK7L4R5RIV4LPcyAo+YI680rGtKJvNbq64ePHe d4bS6AmFFJe2wuh4sQvvO3blRrhFytDwOrKfYFy94+cqD1W7sjVpbP6RisObSWfQJWCx snvUXwLwZ9VWEtJqhsmDPHY1lb9yA5hntAUf5r+mqJNKhcgyEkWt2kPJwVn3kum4JqzE A1cZqCpmORBqBk+E4KvHXrZ1UuOCDUI1vKxHGl9ZY6cj8Jl5tbnYJJEo0TIXEIslAfC+ iQOQ== X-Gm-Message-State: AOAM532L5MNzS2vkTC1Q2JjNVID/YS2/9UvlqmOsDYfMaFgD7XFQM5gt vJL2pgSn9vgAyNfTqA07DF7GCA== X-Google-Smtp-Source: ABdhPJyvwSd59fOf4gmHHNFK3B7uifstEscZKI3Wgj8BZMUSVE8mbPNnw0jNtdQtZjlHMgBGnNPgSw== X-Received: by 2002:ac8:4658:: with SMTP id f24mr22451505qto.375.1619538429846; Tue, 27 Apr 2021 08:47:09 -0700 (PDT) Received: from brians-mbp.lan (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id p186sm2846105qka.66.2021.04.27.08.47.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Apr 2021 08:47:09 -0700 (PDT) From: Brian Rosen Message-Id: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_0A9A5627-118A-43D8-8B5C-CB5BFC966A29" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 27 Apr 2021 11:47:03 -0400 In-Reply-To: Cc: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org To: Bret Jordan References: X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [dispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 15:47:17 -0000 --Apple-Mail=_0A9A5627-118A-43D8-8B5C-CB5BFC966A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am very much interested in this work. My preference would be for a = Proposed Standard. There was a lot of opposition to the idea = previously, so it may be that ISE is all we can get, but I would be = willing to work towards PS, either in a new, short lived work group or = as part of another work group. =20 Brian > On Apr 27, 2021, at 11:27 AM, Bret Jordan = wrote: >=20 > Dear Dispatch, >=20 > Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for = your consideration. This document describes how to use JWS and JCS to = create plain-text JSON signatures. The abstract reads as follows: >=20 > This document describes a method for extending the scope of the JSON = Web Signature (JWS) standard, called JWS/CT. By combining the detached = mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables = JSON objects to remain in the JSON format after being signed (aka "Clear = Text" signing). In addition to supporting a consistent data format, = this arrangement also simplifies documentation, debugging, and logging. = The ability to embed signed JSON objects in other JSON objects, makes = the use of counter-signatures straightforward. >=20 > The data tracker page for this: = https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ = >=20 > As you know there are large ecosystems that needs digital signatures = for plain text JSON data, meaning where the JSON data is not base64 = encoded. This ID provides a solution using existing IETF RFCs to make = this work. Further, this work looks to be adopted by many groups and = organizations from financial services, threat intelligence, and incident = response.=20 >=20 > We are not sure what direction would be best for this work in the = IETF, should we send to the ISE for publication or do you want to create = a working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct = >=20 > Thanks > Bret >=20 > --=20 >=20 > Sent from my TI-99/4A >=20 > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_0A9A5627-118A-43D8-8B5C-CB5BFC966A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = am very much interested in this work.  My preference would be for a = Proposed Standard.  There was a lot of opposition to the idea = previously, so it may be that ISE is all we can get, but I would be = willing to work towards PS, either in a new, short lived work group or = as part of another work group.  

Brian

On Apr = 27, 2021, at 11:27 AM, Bret Jordan <jordan.ietf@gmail.com> wrote:

Dear Dispatch,

Anders Rundgren, = Samuel, Erdtman, and I have been working on an ID for your = consideration. This document describes how to use JWS and JCS to create = plain-text JSON signatures. The abstract reads as follows:

This document describes a method for extending = the scope of the JSON Web Signature (JWS) standard, called JWS/CT.  = By combining the detached mode of JWS with the JSON Canonicalization = Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format = after being signed (aka "Clear Text" signing).  In addition to = supporting a consistent data format, this arrangement also simplifies = documentation, debugging, and logging.  The ability to embed signed = JSON objects in other JSON objects, makes the use of counter-signatures = straightforward.

The data tracker page for = this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large ecosystems that = needs digital signatures for plain text JSON data, meaning where the = JSON data is not base64 encoded. This ID provides a solution using = existing IETF RFCs to make this work. Further, this work looks to be = adopted by many groups and organizations from financial services, threat = intelligence, and incident response.

We = are not sure what direction would be best for this work in the IETF, = should we send to the ISE for publication or do you want to create a = working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct

Thanks
Bret

--

Sent from my TI-99/4A

PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_0A9A5627-118A-43D8-8B5C-CB5BFC966A29-- From nobody Tue Apr 27 09:22:19 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0A83A143C; Tue, 27 Apr 2021 09:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pdlzGfdiGpK; Tue, 27 Apr 2021 09:22:09 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D2D3A1410; Tue, 27 Apr 2021 09:22:09 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FV6V54M8Jzyb8; Tue, 27 Apr 2021 18:22:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> Date: Tue, 27 Apr 2021 18:21:59 +0200 Cc: Bret Jordan , art@ietf.org, DISPATCH , rfc-ise@rfc-editor.org, IETF SecDispatch X-Mao-Original-Outgoing-Id: 641233319.424724-28203518ffff9156d9f15176ac24627d Content-Transfer-Encoding: quoted-printable Message-Id: <38EA765F-6FF9-4C45-95D9-7429612B08EC@tzi.org> References: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 16:22:14 -0000 On 2021-04-27, at 17:47, Brian Rosen wrote: >=20 > There was a lot of opposition to the idea previously, Yes. But there is also some opposition to the weird way this is presented: >> On Apr 27, 2021, at 11:27 AM, Bret Jordan = wrote: >> JWS/CT enables JSON objects to remain in the JSON format after being = signed (aka "Clear Text" signing). =20 We have a lot of ways that enable signed objects to remain in the format = in which they were at signature time. Maybe we can fix the presentation of the idea more towards =E2=80=9Cwe = really liked XMLDsig and want it back for JSON=E2=80=9D, which is = certainly a position one can take. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 27 09:40:32 2021 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 7F7E93A1673; Tue, 27 Apr 2021 09:40:25 -0700 (PDT) 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.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161954162541.21678.15235003146170895724@ietfa.amsl.com> Date: Tue, 27 Apr 2021 09:40:25 -0700 Archived-At: Subject: [dispatch] dispatch - New Meeting Session Request for IETF 111 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: Tue, 27 Apr 2021 16:40:28 -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): 2 Hours Number of Attendees: 100 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 tram secdispatch emailcore asdf sframe jsonpath webtrans regext cbor calext httpapi wpack 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 Tue Apr 27 10:26:13 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E6A3A1812 for ; Tue, 27 Apr 2021 10:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzZA8z3Lwy5r for ; Tue, 27 Apr 2021 10:26:06 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 3FA1A3A1815 for ; Tue, 27 Apr 2021 10:26:06 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id i3so45217807edt.1 for ; Tue, 27 Apr 2021 10:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Btzw9Yc+5c2mn6FeranT96j+omUW8mGBTubLflLm1zY=; b=Egb4qjZVUgKNvzuXp5+jAF9h2W6msptcuhYdKPTEeko61IO1VBFhxdVA5NMMxisLz3 GWbjAEuTWtjXJpLClTdSrgOv0lkn0e4uKN4R/sTH3egGuEvkaJxd+gGGDXtg6COAt0AE kmW+U4KysYHGBUv1T+2tqrDoCAKF8XLoJ2pdEGR6ZWwk+YHbX2tLV5+U6/CwmgbuExKq 5J/GiGfsWOsjkSM00R+h+/rpvxx/3ES2s/4Ktel9D8neMZ7l1j8aNtj6r27ywPgmhMZT 7BXibDzbuOeLL8fOPl6S+jAJmVpcQYjk9U3xr54oqBdlPyPB2a8VV1uuucii48V3ggbA Yu6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Btzw9Yc+5c2mn6FeranT96j+omUW8mGBTubLflLm1zY=; b=Z2mD/G3nkAbxVJVqcY4YA35iQZ6C45oH5JThlmpZdTi8DN52B66TTnpnyQpieInnNc cjsUXsej6aZQKJ0cc0fCdbTgszBriZI8jGw2R9N2OX67zhJeIcB7zCoQGy2jjiiif1tL CEtZwqVDlzazf5mJR5naZzSXDe5GZPS7mcAErQ27UfFTUbJCx6vbblo0vYsk0OIFKm8w yT8mEQJnn46E28a17H1JS7EU5/11pyV3RLG/dyM6tAKKuD6aKfeUwe1zZYXgDjX0WJOp MHxide8ic38a8NZXxSR3NMp/PVLZPtd5TGAsP2O/6KaeJn/pOcMUlo0PLcBMvE1azTRM /BFA== X-Gm-Message-State: AOAM530xhR2xOGCXnOXdfVYmIBFjIS3jlxxgUl2K+Nf8MgFrg5ysMNW+ Y3DzG4j7se5Z6pGEQy/uQkPnFC9x2bF5tmTb3qKR+A== X-Google-Smtp-Source: ABdhPJyBMuP5U0nUo2J7cb5BsVvbebfA1HK+980bw7J+WGwQQRTfNefNyQwKSKx07JgGjz64efUCUTYhxmRBR3HWwBI= X-Received: by 2002:aa7:c7da:: with SMTP id o26mr5807200eds.244.1619544359233; Tue, 27 Apr 2021 10:25:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Myles Borins Date: Tue, 27 Apr 2021 13:25:47 -0400 Message-ID: To: Mathias Bynens Cc: Kirsty P , "Matthew A. Miller" , DISPATCH WG Content-Type: multipart/alternative; boundary="0000000000003b0f4a05c0f78e50" Archived-At: Subject: Re: [dispatch] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 17:26:11 -0000 --0000000000003b0f4a05c0f78e50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Disclaimer: I am one of the authors of the draft. I would like to also express my support for this draft. It imho reflects ecosystem usage, for example there are currently over 6 million files with the .mjs extension on GitHub . The extension is supported in some mimetype collections and DBs, such as that of the python programming language , but still hasn't been adopted by industry standard tools such as apache . The lack of consistency here makes for poor developer experiences and inconsistent experiences across platforms + tools. This draft being accepted would be an extremely strong signal to let folks know that they can implement support for .mjs. Separate from the new extension that will be supported the updated draft includes a number of additional improvements that reflect the current reality of the web. This includes making "text/javascript" COMMON rather than OBSOLETE and an update to the security considerations. Thank you everyone for your time and considerations regarding this matter. On Tue, Apr 27, 2021 at 10:17 AM Mathias Bynens wrote: > Disclaimer: I am one of the authors of this draft. Nevertheless, I > would like to express my support and speak to the importance of its > standardization. > > The draft supersedes the earlier RFC4329, providing updated > definitions to align with what has quickly become implementation > reality, both in web browsers as well as other popular JavaScript > environments such as Node.js. > > Thanks, > Mathias > > On Tue, Apr 27, 2021 at 3:49 PM Kirsty P wrote: > > ________________________________ > > From: Kirsty P > > Sent: 26 April 2021 16:25 > > To: dispatch@ietf.org > > Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th > May > > > > Hi DISPATCH, > > > > Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd > WGLC (Working Group Last Call). Please send your comments and/or > expressions of support to the DISPATCH list. > > > > Longer: the draft was recently updated to address feedback from a revie= w > and from the 2nd WGLC [1]. The authors posted an update to the list with > more information [2]. We (DISPATCH chairs) feel like all the comments hav= e > been addressed, so it's time for 3rd WGLC. > > > > We need to hear positive noises and support for this draft from the WG > before progressing the -08 draft, so please email to signal your > endorsement, even if you have no comments to make. The draft can be found > on datatracker here: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > > > WGLC is open for 2 weeks - so will finish close-of-play on Monday 10th > May. > > > > Kirsty > > (DISPATCH co-chair) > > > > [1] > https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg= 0/ > > [2] > https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzki= s/ > > > > > > > > This information is exempt under the Freedom of Information Act 2000 > (FOIA) and may be exempt under other UK information legislation. Refer an= y > FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown > Copyright =C2=A9 > --0000000000003b0f4a05c0f78e50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Disclaimer: I am one of the authors of the draft.

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

The extension is supported in some mimetype collections and DBs, such as t= hat of the python programming language, but still hasn't been = adopted by industry standard tools such as apache. The lack of consistency her= e makes for poor developer experiences and inconsistent experiences across = platforms=C2=A0+ tools. This draft being accepted would be an extremely str= ong signal to let folks know that they can implement support for .mjs.

Separate from the new extension that will be supported= the updated draft includes a number of additional improvements that reflec= t the current reality of the web. This includes making "text/javascrip= t" COMMON rather than OBSOLETE and an update to the security considera= tions.

Thank you everyone for your time and consid= erations regarding this=C2=A0matter.

On Tue, Apr 27, 2021 at 10:17 AM = Mathias Bynens <mths@google.com&g= t; wrote:
Discla= imer: I am one of the authors of this draft. Nevertheless, I
would like to express my support and speak to the importance of its
standardization.

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

Thanks,
Mathias

On Tue, Apr 27, 2021 at 3:49 PM Kirsty P <Kirsty.p@ncsc.gov.uk> wrote:
> ________________________________
> From: Kirsty P
> Sent: 26 April 2021 16:25
> To: dispatch@ie= tf.org <dispa= tch@ietf.org>
> Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th= May
>
> Hi DISPATCH,
>
> Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd W= GLC (Working Group Last Call). Please send your comments and/or expressions= of support to the DISPATCH list.
>
> Longer: the draft was recently updated to address feedback from a revi= ew and from the 2nd WGLC [1]. The authors posted an update to the list with= more information [2]. We (DISPATCH chairs) feel like all the comments have= been addressed, so it's time for 3rd WGLC.
>
> We need to hear positive noises and support for this draft from the WG= before progressing the -08 draft, so please email to signal your endorseme= nt, even if you have no comments to make. The draft can be found on datatra= cker here: https://datatracker.i= etf.org/doc/draft-ietf-dispatch-javascript-mjs/
>
> WGLC is open for 2 weeks - so will finish close-of-play on Monday 10th= May.
>
> Kirsty
> (DISPATCH co-chair)
>
> [1] https://mailarch= ive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg0/
> [2] https://mailarch= ive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzkis/
>
>
>
> This information is exempt under the Freedom of Information Act 2000 (= FOIA) and may be exempt under other UK information legislation. Refer any F= OIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =C2=A9
--0000000000003b0f4a05c0f78e50-- From nobody Tue Apr 27 10:42:42 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F33A1983; Tue, 27 Apr 2021 10:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHyB5JF1Y75b; Tue, 27 Apr 2021 10:42:31 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 EB71B3A197C; Tue, 27 Apr 2021 10:42:30 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id d10so4492468pgf.12; Tue, 27 Apr 2021 10:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HQL5Wqf3iRLxMjvIGI4OPl0Sd4/TKZ/qOX9ujzTIWVU=; b=K9nHfXu0geV4cePric67yELZVZBVb5od4rVWHn89jcV7cVv1Pf/tlD5SFLhstWHHzX 2ARVi0ZX3gX3EETQha/R/iEepR+XU5iCDefkCgIxt7i06ezZLWdhdS9cFfQJ3y4l+f31 d/O6C78uVTUk5iJN3fgSfDFI2v2hJkRE6IA1lht+VrCoRXRkqssWidQ3DOkSC0jlMTus MpLDRXhTQa+kn6jk8QpOlJTMpSJ/dvpoABR6+zeg1dT9P9o9JyqhV04bPc314vLOM27x 8XoI5Gsu8lI6YhrWJB8dNANItCKF1vcyLW3K1D8rrpT3y3/f7G8JFhWNgSOtRGM1S4WX HQew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HQL5Wqf3iRLxMjvIGI4OPl0Sd4/TKZ/qOX9ujzTIWVU=; b=O/3dNV0wG5wDuMxk5BSBkLilt3cj5y+6Jnl6ObjVNQiN700iM/mcGysxpshyvAonq+ t4f9xVxrA2uf7Pn6YIOMSZJ5yCxkRU2mFT6H1UUsxFFbgsa/m2LCJyYI7dHSLuoLZVwf jCjk23i7rtlBhGnYekSvg+RZ3GZUZwRSQmYDMk8KP0v6YunAVqA6weeIlOYi3YIdVkwk 8p1Mg+p5DreeSXXdJWdNRzxIoNzubiCYQHoFp7LtbPXj5nX2nfJp9erB6D1oHi8mHPcA Ifs/WXJuiCR7hCLbJESGWidp4/InXHABRC9MVoOM5qjY/EWfRIHair+/6bA99l/lUmzu wcPw== X-Gm-Message-State: AOAM532/dU56NJZuQCj/4paG8ss7Cy/2DSnl40vKG6tNSoV8AjCSzX+m lWrrfUO9Y6af5vaSQOpxo9xCTlVlHBk= X-Google-Smtp-Source: ABdhPJwNO+WwxktDW8hDxLzBvx4km7rafVhuv1yWs9XHML4s6w4e4PiGcAXMO2jLJouP/iJhxgdQ2g== X-Received: by 2002:a62:4c3:0:b029:27c:892f:8e22 with SMTP id 186-20020a6204c30000b029027c892f8e22mr155737pfe.6.1619545349138; Tue, 27 Apr 2021 10:42:29 -0700 (PDT) Received: from smtpclient.apple ([136.36.112.224]) by smtp.gmail.com with ESMTPSA id k17sm2876516pji.47.2021.04.27.10.42.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Apr 2021 10:42:28 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9EA67B10-5CE9-4BAB-B068-859BEB87D62A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 27 Apr 2021 11:42:26 -0600 In-Reply-To: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> Cc: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org To: Brian Rosen References: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [dispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 17:42:36 -0000 --Apple-Mail=_9EA67B10-5CE9-4BAB-B068-859BEB87D62A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian, Yes, there are are lot of people and organizations that are looking for = a solution like this. There are several that I know of that are already = looking to adopt this or something similar in production. I also know = Anders has been doing a lot of work in the financial sector using this = for payment processing. What people need to realize is that plain text = signatures and plain text JSON is a fundamental requirement. The proof = of concept code I have written so far shows that this works, and works = really well.=20 It is great to hear that you would support this work, either through a = PS or via the ISE. Please let us know if you have any feedback on the = ID.=20 Thanks Bret > On Apr 27, 2021, at 9:47 AM, Brian Rosen wrote: >=20 > I am very much interested in this work. My preference would be for a = Proposed Standard. There was a lot of opposition to the idea = previously, so it may be that ISE is all we can get, but I would be = willing to work towards PS, either in a new, short lived work group or = as part of another work group. =20 >=20 > Brian >=20 >> On Apr 27, 2021, at 11:27 AM, Bret Jordan > wrote: >>=20 >> Dear Dispatch, >>=20 >> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID = for your consideration. This document describes how to use JWS and JCS = to create plain-text JSON signatures. The abstract reads as follows: >>=20 >> This document describes a method for extending the scope of the JSON = Web Signature (JWS) standard, called JWS/CT. By combining the detached = mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables = JSON objects to remain in the JSON format after being signed (aka "Clear = Text" signing). In addition to supporting a consistent data format, = this arrangement also simplifies documentation, debugging, and logging. = The ability to embed signed JSON objects in other JSON objects, makes = the use of counter-signatures straightforward. >>=20 >> The data tracker page for this: = https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ = >>=20 >> As you know there are large ecosystems that needs digital signatures = for plain text JSON data, meaning where the JSON data is not base64 = encoded. This ID provides a solution using existing IETF RFCs to make = this work. Further, this work looks to be adopted by many groups and = organizations from financial services, threat intelligence, and incident = response.=20 >>=20 >> We are not sure what direction would be best for this work in the = IETF, should we send to the ISE for publication or do you want to create = a working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct = >>=20 >> Thanks >> Bret >>=20 >> --=20 >>=20 >> Sent from my TI-99/4A >>=20 >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 --Apple-Mail=_9EA67B10-5CE9-4BAB-B068-859BEB87D62A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Brian,

Yes, there = are are lot of people and organizations that are looking for a solution = like this. There are several that I know of that are already looking to = adopt this or something similar in production. I also know Anders has = been doing a lot of work in the financial sector using this for payment = processing. What people need to realize is that plain text signatures = and plain text JSON is a fundamental requirement. The proof of concept = code I have written so far shows that this works, and works really = well. 

It = is great to hear that you would support this work, either through a PS = or via the ISE. Please let us know if you have any feedback on the = ID. 

Thanks
Bret





On Apr = 27, 2021, at 9:47 AM, Brian Rosen <br@brianrosen.net> wrote:

I am very much = interested in this work.  My preference would be for a Proposed = Standard.  There was a lot of opposition to the idea previously, so = it may be that ISE is all we can get, but I would be willing to work = towards PS, either in a new, short lived work group or as part of = another work group.  

Brian

On Apr 27, 2021, at 11:27 AM, = Bret Jordan <jordan.ietf@gmail.com> wrote:

Dear Dispatch,

Anders Rundgren, = Samuel, Erdtman, and I have been working on an ID for your = consideration. This document describes how to use JWS and JCS to create = plain-text JSON signatures. The abstract reads as follows:

This document describes a method for extending = the scope of the JSON Web Signature (JWS) standard, called JWS/CT.  = By combining the detached mode of JWS with the JSON Canonicalization = Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format = after being signed (aka "Clear Text" signing).  In addition to = supporting a consistent data format, this arrangement also simplifies = documentation, debugging, and logging.  The ability to embed signed = JSON objects in other JSON objects, makes the use of counter-signatures = straightforward.

The data tracker page for = this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large ecosystems that = needs digital signatures for plain text JSON data, meaning where the = JSON data is not base64 encoded. This ID provides a solution using = existing IETF RFCs to make this work. Further, this work looks to be = adopted by many groups and organizations from financial services, threat = intelligence, and incident response.

We = are not sure what direction would be best for this work in the IETF, = should we send to the ISE for publication or do you want to create a = working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct

Thanks
Bret

--

Sent from my TI-99/4A

PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


= --Apple-Mail=_9EA67B10-5CE9-4BAB-B068-859BEB87D62A-- From nobody Tue Apr 27 16:49:04 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE6F3A25DC; Tue, 27 Apr 2021 16:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbyaJyerCugv; Tue, 27 Apr 2021 16:48:53 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 7E3083A25D9; Tue, 27 Apr 2021 16:48:53 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id i21-20020a05600c3555b029012eae2af5d4so8033445wmq.4; Tue, 27 Apr 2021 16:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IwfoDDY9l4QVtUBqexOAOFzt0mCO2fk8g0w3v01ySEM=; b=W5vgFXE6jXcIh07my29QfBM6ydkOnhDOsAYakaMDjQ9NnNln/ip2LU1UktTVpfOhEy +L+oKt+R9tWrwzLi+hzt+Q3FKfYqvxp73D6eFltMHcFsdAV0uh8uSKUPy6m7DmSp9PvH 962BbXaREG/lSk03fOvgYqAduadEl1fo7z2fUPdCJTyVvG3b0P50mQMNdU2X4R/VTlxs XyHHBC2HSniq0ZXWVggsMuJ+bka5uA8IPzCyabXhZIHPBM76XxDOgLOUVmXLtO0iexGb IApVw9+NN3gJqbnI3hFPhFxjTsFFWoVyvVVmk/ovxiOrAc42Lh9OpXAxudgK6dQchxOm DcJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IwfoDDY9l4QVtUBqexOAOFzt0mCO2fk8g0w3v01ySEM=; b=JBBt5p1sh2oRq0H5olgvjJ3yVJA3wRjewU+Jh6aWHbyMgOJ8dYaGNrtsYsKkpQSD06 a8Ff9ifaXq0TVkWWNQyS2H+bw82EQqaiImovDdrKllEJWbbOLTUMBS1xyYb3dpPxB+2Z DuSc8AkbkxegFO3B/tDkSZ5ifZCsFUnhomChtdg1P9woLQFd9Jch1QMneaTH8hdlcyKj JB4J23xDv0IOemdbt7CYEjCaLPtvi4v7UcXti6wJ8q279v2BWRUUpcs4aIY0HOKUD0OQ Eg/OJbQnbrHzNhQ3noM4nRC1TCQGUchdCcRhl76GtVuvMQSTmKxiOD2LFpCJE8kgEonQ Ti+w== X-Gm-Message-State: AOAM533n8Y/nJbGvfW7F2H8aOC7ONZyiVlwTZ9kDHbg0L+aOhbFO+34D lvcWC2TzHWLMgAImZ5vIBTM= X-Google-Smtp-Source: ABdhPJxy4TVFD1/fZjExeGXbBd8KtIuvHovfaaJy3crmN6BmKMuCn7EEUJjvPnWDxMB3Wk3SzUTTXQ== X-Received: by 2002:a1c:e089:: with SMTP id x131mr9262910wmg.102.1619567330353; Tue, 27 Apr 2021 16:48:50 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id l12sm5770171wrm.76.2021.04.27.16.48.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Apr 2021 16:48:49 -0700 (PDT) To: Carsten Bormann Cc: art@ietf.org, IETF SecDispatch , DISPATCH , rfc-ise@rfc-editor.org References: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> <38EA765F-6FF9-4C45-95D9-7429612B08EC@tzi.org> From: Anders Rundgren Message-ID: Date: Wed, 28 Apr 2021 01:48:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <38EA765F-6FF9-4C45-95D9-7429612B08EC@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 23:48:58 -0000 On 2021-04-27 18:21, Carsten Bormann wrote: > On 2021-04-27, at 17:47, Brian Rosen wrote: >> >> There was a lot of opposition to the idea previously, > > Yes. Dear Carsten, There were indeed a lot of opposition at IETF-104 but nobody has to date bothered providing a single example showing why this idea {w|sh}ould not work [1]. If we take the better [and fully standardized] alternative (JWS), it transforms a JSON object into a Base64Url-encoded string and then puts it into a specific signature container. That is, the result bears very little similarity to the original which obviously is a drawback. Then a [moderately] skillful attacker replaces the algorithm in the JWS header with the standardized "none" and the whole thing passes validation with flying colors [2]. Anyway, variants of detached (enveloped) JWS signatures in JSON are likely to become a de-facto standard. Here is an example from a very active group withing the W3C: https://w3c-ccg.github.io/ld-proofs/#example-2-a-simple-signed-linked-data-document Feel free rearchitecting https://fido-web-pay.github.io/ using the current JOSE stack; it might even be fun :) BTW, I have just started the design of a CBOR library needed for dealing with CTAP2/FIDO for the project above. CBOR seems pretty cool. Regards, Anders 1] In all fairness, it does require a bit of work for the application developer who may have to adjust the parsing scheme (not the parser) for things like RFC3339 data. 2] In a n00b world, where developers do not understand that a compliant JWS library does not necessarily come with suitable default policies. > > But there is also some opposition to the weird way this is presented: > >>> On Apr 27, 2021, at 11:27 AM, Bret Jordan wrote: >>> JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing). > > We have a lot of ways that enable signed objects to remain in the format in which they were at signature time. > > Maybe we can fix the presentation of the idea more towards “we really liked XMLDsig and want it back for JSON”, which is certainly a position one can take. > > Grüße, Carsten > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Apr 27 18:39:19 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CA13A0D12; Tue, 27 Apr 2021 18:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=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 HIkFvXT5-N-h; Tue, 27 Apr 2021 18:39:13 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 A7FCF3A0D06; Tue, 27 Apr 2021 18:39:12 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id b23so14034673lfv.8; Tue, 27 Apr 2021 18:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0LlPwsYif1ZdRk37XhKly0/3Vk0+Il3lcnWntqEHkFY=; b=LkhdzZPvGAng3qQAX0ZwvLZW9l1gQK36exdwWmKJlZFZs5ByClGuHgeAwodBYfA13Y OKIbBveJXFZ1dNV+51HyeB65Vu4X0DYGsXGLWi0nLBvzstZ1c2t7HrhPngWqpvFTqNsX TR1JQ7ofRnte1Gw5V3BUM5rugvA8CxQ7tgbFhMmii/WIW6kZGDODxDmSWvnfP0ZDCXqJ G22mHJvfsjF0S/PnFoqsQDI/GEJR+Qi+nOmgehT+mkiYhZszLPQyJDXewXB+fLx4p+SS C2DuNw+0RnwzHtcyI3NPvDOQZC1gtxsSUxtK8vkG4S0KFUYcp7kDVCWBZf4Ut06jNoTe 0NDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0LlPwsYif1ZdRk37XhKly0/3Vk0+Il3lcnWntqEHkFY=; b=gckhtn99oOwOrk2jB49xtRPoGp1DqmhrZT+pcIHKc5QX/P44yDhAtUsBOI+y5Iylru DpKmIA/alxc2JCvAkY+gQDIZWRNM4e2J3LGBy+YMkv5i+6DGg9sYK9WPaP9Db9wXvDfk mO0VEGoFmZu3DqSi2/VhEDUGBrRmxvXzUA95JldtK8mSP7DFSxY/wPG0skBFEvUAo0Ze KlG7qRgZrHyqU/F3ZLLjbGS2kzrSbO4WfcFMvSH01/NudYSmqZI7sn4saiwGj5gWMzM4 5EXoNwDV6X3vxEF3D+VqIQAr64LmRcgw5uYL8eUBEFEpy2bZ5UWKV+ncQf9h8mmTcQZ7 wDEg== X-Gm-Message-State: AOAM532zu8xI0PUtth2DYBxfOcIWW6Y7z7HVwPzRsIhWWvyBb+R7fkLo D9zlb2RumCItviw19KhxcaN7Kj25xfj/d9MKmjM= X-Google-Smtp-Source: ABdhPJw8f5eT1yM5MK/Ggfat3cQ3wyTcYolJiPv06wYMOyOecG7fHYeQkelj4Cu+KrqZh468QqAqHi1ZRKNT/CrXsYg= X-Received: by 2002:a05:6512:92e:: with SMTP id f14mr18721818lft.347.1619573949962; Tue, 27 Apr 2021 18:39:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 27 Apr 2021 18:38:33 -0700 Message-ID: To: Bret Jordan Cc: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org Content-Type: multipart/alternative; boundary="000000000000f9a0a505c0fe71c7" Archived-At: Subject: Re: [dispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 01:39:18 -0000 --000000000000f9a0a505c0fe71c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am supportive of this work, and would also be willing to work towards a PS. I am seeing rapid growth in the demand to embed JWS in JWS. Given my experience with XML-DSig (see below) making it more XML-DSig like does not sound like a good thing. For any interested in some JWT history, when we were brewing up what became OAuth 2.0, we did not want to tie a token format to the implementation as many deployments had their own proprietary token formats -- but we knew new deployments would benefit from standardizing a token. Our requirements were: - URL safe (access tokens at the time were often passed as a query parameter -- I know, not the best idea, but working with what people wanted= ) - HTTP header safe - richer than name / value pairs Options we considered: ASN.1 - the 60s are calling and want their data back XML-DSig - not URL safe, large size, and I personally had many scars canonicalizing XML. (An earlier company of mine had a contract to build XML-DSig libraries for a few languages) JSON was becoming very cool at that time, and with base 64 URL safe encoding the string, it was URL safe, and treating the JSON text as binary dealt with the canonicalization concerns -- and JSON canonicalization did not exist. Using a dot as the separator between header, payload, and signature made it easy to parse. The dot was URL safe, but not in the base 64 set. And Simple Web Tokens were born -- to be renamed JSON Web Tokens. /Dick =E1=90=A7 On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan wrote: > Dear Dispatch, > > Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for > your consideration. This document describes how to use JWS and JCS to > create plain-text JSON signatures. The abstract reads as follows: > > This document describes a method for extending the scope of the JSON Web > Signature (JWS) standard, called JWS/CT. By combining the detached mode = of > JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON > objects to remain in the JSON format after being signed (aka "Clear Text" > signing). In addition to supporting a consistent data format, this > arrangement also simplifies documentation, debugging, and logging. The > ability to embed signed JSON objects in other JSON objects, makes the use > of counter-signatures straightforward. > > The data tracker page for this: > https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ > > As you know there are large ecosystems that needs digital signatures for > plain text JSON data, meaning where the JSON data is not base64 encoded. > This ID provides a solution using existing IETF RFCs to make this work. > Further, this work looks to be adopted by many groups and organizations > from financial services, threat intelligence, and incident response. > > We are not sure what direction would be best for this work in the IETF, > should we send to the ISE for publication or do you want to create a > working group. Ultimately there is a lot of work that could be done in th= is > space to meet the needs of the market. We would be happy with releasing > these IDs for ISE publication, or for creating a working group to move th= em > forward. It is just important to note that the market is in desperate nee= d > of these solutions. If you want to take it for a spin, there is a JWS/CT > playground at: https://mobilepki.org/jws-ct > > Thanks > Bret > > -- > > Sent from my TI-99/4A > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --000000000000f9a0a505c0fe71c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am supportive of this work, and would also be willing to= work towards a PS. I am seeing rapid growth in the demand to embed JWS in = JWS.

Given my experience with XML-DSig (see below) makin= g it more XML-DSig like does not sound like a good thing.
=C2=A0
For any interested=C2=A0in some JWT history, when we were brewing up = what became OAuth 2.0, we did not want to tie a token format to the impleme= ntation as many deployments had their own proprietary token formats -- but = we knew new deployments would benefit=C2=A0from standardizing a token.

Our requirements were:
- URL safe (access to= kens at the time were often passed as a query parameter=C2=A0-- I know, not= the best idea, but working=C2=A0with what people wanted)
- HTTP = header safe
- richer than name / value pairs

=
Options we considered:
ASN.1 - the 60s are calling and want = their data back
XML-DSig - not URL safe, large size, and I person= ally had many scars canonicalizing XML. (An earlier company of mine had a c= ontract to build XML-DSig libraries for a few languages)
=C2=A0
JSON was becoming very cool at that time, and with base 64 URL saf= e encoding the string, it was URL safe, and treating the JSON text as binar= y dealt with the canonicalization concerns -- and JSON canonicalization did= not exist.

Using a dot as the separator=C2=A0betw= een header, payload, and signature made it easy to parse. The dot was URL s= afe, but not in the base 64 set.

And Simple Web To= kens were born -- to be renamed JSON Web Tokens.

/= Dick




=E1=90=A7

On Tue, Apr 27, 2021 at 8:28 AM Bre= t Jordan <jor= dan.ietf@gmail.com> wrote:
Dear Dispatch,

Anders Rundgren, S= amuel, Erdtman, and I have been working on an ID for your consideration. Th= is document describes how to use JWS and JCS to create plain-text JSON sign= atures. The abstract reads as follows:

This document describes a met= hod for extending the scope of the JSON Web Signature (JWS) standard, calle= d JWS/CT.=C2=A0 By combining the detached mode of JWS with the JSON Canonic= alization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON f= ormat after being signed (aka "Clear Text" signing).=C2=A0 In add= ition to supporting a consistent data format, this arrangement also simplif= ies documentation, debugging, and logging.=C2=A0 The ability to embed signe= d JSON objects in other JSON objects, makes the use of counter-signatures s= traightforward.

The data tracker page for this: https://dat= atracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are= large ecosystems that needs digital signatures for plain text JSON data, m= eaning where the JSON data is not base64 encoded. This ID provides a soluti= on using existing IETF RFCs to make this work. Further, this work looks to = be adopted by many groups and organizations from financial services, threat= intelligence, and incident response.

We are not sure what directio= n would be best for this work in the IETF, should we send to the ISE for pu= blication or do you want to create a working group. Ultimately there is a l= ot of work that could be done in this space to meet the needs of the market= . We would be happy with releasing these IDs for ISE publication, or for cr= eating a working group to move them forward. It is just important to note t= hat the market is in desperate need of these solutions. If you want to take= it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct

<= /div>
Thanks
Bret

--

Sent from my TI-99/4A
PGP Fingerprint:= =C2=A063B4 FC53 680A 6B7D 14= 47 =C2=A0F2C0 74F8 ACAE=C2=A07415 0050
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--000000000000f9a0a505c0fe71c7-- From nobody Tue Apr 27 19:29:18 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EC83A1062; Tue, 27 Apr 2021 19:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 P3B8DUKI29gA; Tue, 27 Apr 2021 19:29:07 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 45C583A1060; Tue, 27 Apr 2021 19:29:07 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id v191so921588pfc.8; Tue, 27 Apr 2021 19:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ImyPWRB0TPrgYbHBaH1s6y5suW8JVeP8WJQwwdM+NuE=; b=uldO5ph3HQ6tize5lfZnibljd4hfjiw2dVFg0AySJWsBh8qzNs8ovo8PoyDuUQrm0U JiPJHYtI8VIA1WK5Y6sRPr80ybhGWhZHFznH8jU4Bw4JIMShLZgtvokDjxcBA4gwTyX8 C0h/PGbS6Ml3fZvQQRrS8shOJjV2NRo1VfMrNBLT/+fwtjEgMgvZHu3WpFdLt8Ur3PbX UH+n/7b6W0CiG8I1LA8PNTaZnFLQXYJ1euZAtv8nrV9cIVBmMLfqsxHT91n9QheXmpOF /DYJudYhRkk38h88es2lBPecuF8O6lik+5ET7W8Vs1S5gC5Mi+nUqv5CNPzrqHNyD6fm K2gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ImyPWRB0TPrgYbHBaH1s6y5suW8JVeP8WJQwwdM+NuE=; b=Gqn3/xO8tO9IigTYw2xJppBNk/HjNE5QHJ+3Xrkh2l2G0GBoH58l/qrJiQ8IRasg78 DeFn1QIifVHsy7FQGeAuahvhqkJrhebGHNQiMCvEpeHKVKJOLYNdMrTwxCFxTZz4Hzea oCTu2UQtDPxG7O/KMWpJwr1IBrBF/wZina+jvpmI61TY0FCgOMusDuuROu4mRB2m/d0p gy9aOAoQvjGiPJ4Tfkw6GAi+JFlsMZX7fEU+HRpyzHBFMVznJPOudlV3STmOOVJ+yuah d+Zr+Djf8PRbQ3/OR/jTnZJuSoOUND8SZmG9n2B5oym8IS5FwwhJoa52mSLGIYW2tCCf sTRg== X-Gm-Message-State: AOAM531CSlAILe+nUO6G7gZu7ttMCbrowRvGZPlTXvenvHSWK+0WvDGs CIy9rGi4xPIrdP/L28LUMctidDQ6JG0= X-Google-Smtp-Source: ABdhPJwu0LDVUuFHjGFhT23YsF+2R0tGCe4+j3y7BQy8+St96kdI5/f+HbAIQrjd+koMElDjBRjpjw== X-Received: by 2002:a63:6c06:: with SMTP id h6mr25448864pgc.95.1619576945200; Tue, 27 Apr 2021 19:29:05 -0700 (PDT) Received: from [10.128.64.110] ([136.36.112.224]) by smtp.gmail.com with ESMTPSA id gf21sm3535887pjb.20.2021.04.27.19.29.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Apr 2021 19:29:04 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-01B157E7-5699-4FBC-BA95-089ED16BBAC6 Content-Transfer-Encoding: 7bit From: Bret Jordan Mime-Version: 1.0 (1.0) Date: Tue, 27 Apr 2021 20:29:03 -0600 Message-Id: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> References: Cc: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org In-Reply-To: To: Dick Hardt X-Mailer: iPhone Mail (18D70) Archived-At: Subject: Re: [dispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 02:29:12 -0000 --Apple-Mail-01B157E7-5699-4FBC-BA95-089ED16BBAC6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Luckily this time we have RFC8785 that solves the canonicalization problem f= or JSON.=20 Bret=20 Sent from my Commodore 64 PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > On Apr 27, 2021, at 7:39 PM, Dick Hardt wrote: >=20 > =EF=BB=BF > I am supportive of this work, and would also be willing to work towards a P= S. I am seeing rapid growth in the demand to embed JWS in JWS. >=20 > Given my experience with XML-DSig (see below) making it more XML-DSig like= does not sound like a good thing. > =20 > For any interested in some JWT history, when we were brewing up what becam= e OAuth 2.0, we did not want to tie a token format to the implementation as m= any deployments had their own proprietary token formats -- but we knew new d= eployments would benefit from standardizing a token. >=20 > Our requirements were: > - URL safe (access tokens at the time were often passed as a query paramet= er -- I know, not the best idea, but working with what people wanted) > - HTTP header safe > - richer than name / value pairs >=20 > Options we considered: > ASN.1 - the 60s are calling and want their data back > XML-DSig - not URL safe, large size, and I personally had many scars canon= icalizing XML. (An earlier company of mine had a contract to build XML-DSig l= ibraries for a few languages) > =20 > JSON was becoming very cool at that time, and with base 64 URL safe encodi= ng the string, it was URL safe, and treating the JSON text as binary dealt w= ith the canonicalization concerns -- and JSON canonicalization did not exist= . >=20 > Using a dot as the separator between header, payload, and signature made i= t easy to parse. The dot was URL safe, but not in the base 64 set. >=20 > And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >=20 > /Dick >=20 >=20 >=20 >=20 > =E1=90=A7 >=20 >> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan wrote= : >> Dear Dispatch, >>=20 >> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for yo= ur consideration. This document describes how to use JWS and JCS to create p= lain-text JSON signatures. The abstract reads as follows: >>=20 >> This document describes a method for extending the scope of the JSON Web S= ignature (JWS) standard, called JWS/CT. By combining the detached mode of J= WS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects t= o remain in the JSON format after being signed (aka "Clear Text" signing). I= n addition to supporting a consistent data format, this arrangement also sim= plifies documentation, debugging, and logging. The ability to embed signed J= SON objects in other JSON objects, makes the use of counter-signatures strai= ghtforward. >>=20 >> The data tracker page for this: https://datatracker.ietf.org/doc/draft-jo= rdan-jws-ct/ >>=20 >> As you know there are large ecosystems that needs digital signatures for p= lain text JSON data, meaning where the JSON data is not base64 encoded. This= ID provides a solution using existing IETF RFCs to make this work. Further,= this work looks to be adopted by many groups and organizations from financi= al services, threat intelligence, and incident response.=20 >>=20 >> We are not sure what direction would be best for this work in the IETF, s= hould we send to the ISE for publication or do you want to create a working g= roup. Ultimately there is a lot of work that could be done in this space to m= eet the needs of the market. We would be happy with releasing these IDs for I= SE publication, or for creating a working group to move them forward. It is j= ust important to note that the market is in desperate need of these solution= s. If you want to take it for a spin, there is a JWS/CT playground at: https= ://mobilepki.org/jws-ct >>=20 >> Thanks >> Bret >>=20 >> --=20 >>=20 >> Sent from my TI-99/4A >>=20 >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art --Apple-Mail-01B157E7-5699-4FBC-BA95-089ED16BBAC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Luckily this time we have RFC8785 that solv= es the canonicalization problem for JSON. 

Bret 

Sent from my Commodore 64

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C= 0 74F8 ACAE 7415 0050

<= blockquote type=3D"cite">On Apr 27, 2021, at 7:39 PM, Dick Hardt <dick.ha= rdt@gmail.com> wrote:

=EF=BB=BF
I am supportive of this work, an= d would also be willing to work towards a PS. I am seeing rapid growth in th= e demand to embed JWS in JWS.

Given my experience with XM= L-DSig (see below) making it more XML-DSig like does not sound like a good t= hing.
 
For any interested in some JWT history, wh= en we were brewing up what became OAuth 2.0, we did not want to tie a token f= ormat to the implementation as many deployments had their own proprietary to= ken formats -- but we knew new deployments would benefit from standardi= zing a token.

Our requirements were:
- UR= L safe (access tokens at the time were often passed as a query parameter&nbs= p;-- I know, not the best idea, but working with what people wanted)
- HTTP header safe
- richer than name / value pairs
<= div>
Options we considered:
ASN.1 - the 60s are call= ing and want their data back
XML-DSig - not URL safe, large size, a= nd I personally had many scars canonicalizing XML. (An earlier company of mi= ne had a contract to build XML-DSig libraries for a few languages)
 
JSON was becoming very cool at that time, and with base 64= URL safe encoding the string, it was URL safe, and treating the JSON text a= s binary dealt with the canonicalization concerns -- and JSON canonicalizati= on did not exist.

Using a dot as the separator = ;between header, payload, and signature made it easy to parse. The dot was U= RL safe, but not in the base 64 set.

And Simple Web= Tokens were born -- to be renamed JSON Web Tokens.

/Dick




=E1=90=A7

On Tue, Apr 27= , 2021 at 8:28 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Dear Dispatch,

A= nders Rundgren, Samuel, Erdtman, and I have been working on an ID for your c= onsideration. This document describes how to use JWS and JCS to create plain= -text JSON signatures. The abstract reads as follows:

This document d= escribes a method for extending the scope of the JSON Web Signature (JWS) st= andard, called JWS/CT.  By combining the detached mode of JWS with the J= SON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in t= he JSON format after being signed (aka "Clear Text" signing).  In addit= ion to supporting a consistent data format, this arrangement also simplifies= documentation, debugging, and logging.  The ability to embed signed JS= ON objects in other JSON objects, makes the use of counter-signatures straig= htforward.

The data tracker page for this: https://datatracke= r.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large e= cosystems that needs digital signatures for plain text JSON data, meaning wh= ere the JSON data is not base64 encoded. This ID provides a solution using e= xisting IETF RFCs to make this work. Further, this work looks to be adopted b= y many groups and organizations from financial services, threat intelligence= , and incident response.

We are not sure what direction would be bes= t for this work in the IETF, should we send to the ISE for publication or do= you want to create a working group. Ultimately there is a lot of work that c= ould be done in this space to meet the needs of the market. We would be happ= y with releasing these IDs for ISE publication, or for creating a working gr= oup to move them forward. It is just important to note that the market is in= desperate need of these solutions. If you want to take it for a spin, there= is a JWS/CT playground at: https://mobilepki.org/jws-ct

Thanks
Bret

--

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415= 0050
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
= --Apple-Mail-01B157E7-5699-4FBC-BA95-089ED16BBAC6-- From nobody Tue Apr 27 23:52:25 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B873A1CA8 for ; Tue, 27 Apr 2021 23:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 m4V49T_6rFEo for ; Tue, 27 Apr 2021 23:52:18 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (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 7C7963A1CA1 for ; Tue, 27 Apr 2021 23:52:18 -0700 (PDT) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with UTF8SMTP id 2EC2D1A91E4F for ; Wed, 28 Apr 2021 08:52:07 +0200 (CEST) Received: from s630.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with UTF8SMTP id 1E62B2E2B083; Wed, 28 Apr 2021 08:52:07 +0200 (CEST) Received: from s475.loopia.se (unknown [172.22.191.5]) by s630.loopia.se (Postfix) with UTF8SMTP id CA91213B9437; Wed, 28 Apr 2021 08:52:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s934.loopia.se ([172.22.191.5]) by s475.loopia.se (s475.loopia.se [172.22.190.15]) (amavisd-new, port 10024) with UTF8LMTP id e98z6PW06j4v; Wed, 28 Apr 2021 08:52:05 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.1.219] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s934.loopia.se (Postfix) with UTF8SMTPSA id 46D997CEA0F; Wed, 28 Apr 2021 08:52:05 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------2LurtlQsQhRwHdctf4Ws9n0f" Message-ID: <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> Date: Wed, 28 Apr 2021 08:52:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Thunderbird/88.0 Content-Language: en-US To: Bret Jordan , Dick Hardt Cc: art@ietf.org, DISPATCH , rfc-ise@rfc-editor.org, IETF SecDispatch References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> From: Stefan Santesson Organization: 3xA Security AB In-Reply-To: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> Archived-At: Subject: Re: [dispatch] [Secdispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 06:52:24 -0000 This is a multi-part message in MIME format. --------------2LurtlQsQhRwHdctf4Ws9n0f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit How is this different/better than implementing RFC 7797 and apply the header b64=false in order to carry plaintext JSON in the payload? /Stefan On 2021-04-28 04:29, Bret Jordan wrote: > Luckily this time we have RFC8785 that solves the canonicalization > problem for JSON.  > > Bret  > > Sent from my Commodore 64 > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 > >> On Apr 27, 2021, at 7:39 PM, Dick Hardt wrote: >> >>  >> I am supportive of this work, and would also be willing to work >> towards a PS. I am seeing rapid growth in the demand to embed JWS in >> JWS. >> >> Given my experience with XML-DSig (see below) making it more XML-DSig >> like does not sound like a good thing. >>   >> For any interested in some JWT history, when we were brewing up what >> became OAuth 2.0, we did not want to tie a token format to the >> implementation as many deployments had their own proprietary token >> formats -- but we knew new deployments would benefit from >> standardizing a token. >> >> Our requirements were: >> - URL safe (access tokens at the time were often passed as a query >> parameter -- I know, not the best idea, but working with what >> people wanted) >> - HTTP header safe >> - richer than name / value pairs >> >> Options we considered: >> ASN.1 - the 60s are calling and want their data back >> XML-DSig - not URL safe, large size, and I personally had many scars >> canonicalizing XML. (An earlier company of mine had a contract to >> build XML-DSig libraries for a few languages) >>   >> JSON was becoming very cool at that time, and with base 64 URL safe >> encoding the string, it was URL safe, and treating the JSON text as >> binary dealt with the canonicalization concerns -- and JSON >> canonicalization did not exist. >> >> Using a dot as the separator between header, payload, and signature >> made it easy to parse. The dot was URL safe, but not in the base 64 set. >> >> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >> >> /Dick >> >> >> >> >> ᐧ >> >> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan >> wrote: >> >> Dear Dispatch, >> >> Anders Rundgren, Samuel, Erdtman, and I have been working on an >> ID for your consideration. This document describes how to use JWS >> and JCS to create plain-text JSON signatures. The abstract reads >> as follows: >> >> This document describes a method for extending the scope of the >> JSON Web Signature (JWS) standard, called JWS/CT.  By combining >> the detached mode of JWS with the JSON Canonicalization Scheme >> (JCS), JWS/CT enables JSON objects to remain in the JSON format >> after being signed (aka "Clear Text" signing).  In addition to >> supporting a consistent data format, this arrangement also >> simplifies documentation, debugging, and logging.  The ability >> to embed signed JSON objects in other JSON objects, makes the use >> of counter-signatures straightforward. >> >> The data tracker page for this: >> https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ >> >> As you know there are large ecosystems that needs digital >> signatures for plain text JSON data, meaning where the JSON data >> is not base64 encoded. This ID provides a solution using existing >> IETF RFCs to make this work. Further, this work looks to be >> adopted by many groups and organizations from financial services, >> threat intelligence, and incident response. >> >> We are not sure what direction would be best for this work in the >> IETF, should we send to the ISE for publication or do you want to >> create a working group. Ultimately there is a lot of work that >> could be done in this space to meet the needs of the market. We >> would be happy with releasing these IDs for ISE publication, or >> for creating a working group to move them forward. It is just >> important to note that the market is in desperate need of these >> solutions. If you want to take it for a spin, there is a JWS/CT >> playground at: https://mobilepki.org/jws-ct >> >> Thanks >> Bret >> >> -- >> >> Sent from my TI-99/4A >> >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 >> 0050 >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >> > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --------------2LurtlQsQhRwHdctf4Ws9n0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

How is this different/better than implementing RFC 7797 and apply the header b64=false in order to carry plaintext JSON in the payload?

/Stefan


On 2021-04-28 04:29, Bret Jordan wrote:
Luckily this time we have RFC8785 that solves the canonicalization problem for JSON. 

Bret 

Sent from my Commodore 64

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Apr 27, 2021, at 7:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


I am supportive of this work, and would also be willing to work towards a PS. I am seeing rapid growth in the demand to embed JWS in JWS.

Given my experience with XML-DSig (see below) making it more XML-DSig like does not sound like a good thing.
 
For any interested in some JWT history, when we were brewing up what became OAuth 2.0, we did not want to tie a token format to the implementation as many deployments had their own proprietary token formats -- but we knew new deployments would benefit from standardizing a token.

Our requirements were:
- URL safe (access tokens at the time were often passed as a query parameter -- I know, not the best idea, but working with what people wanted)
- HTTP header safe
- richer than name / value pairs

Options we considered:
ASN.1 - the 60s are calling and want their data back
XML-DSig - not URL safe, large size, and I personally had many scars canonicalizing XML. (An earlier company of mine had a contract to build XML-DSig libraries for a few languages)
 
JSON was becoming very cool at that time, and with base 64 URL safe encoding the string, it was URL safe, and treating the JSON text as binary dealt with the canonicalization concerns -- and JSON canonicalization did not exist.

Using a dot as the separator between header, payload, and signature made it easy to parse. The dot was URL safe, but not in the base 64 set.

And Simple Web Tokens were born -- to be renamed JSON Web Tokens.

/Dick




ᐧ

On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Dear Dispatch,

Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for your consideration. This document describes how to use JWS and JCS to create plain-text JSON signatures. The abstract reads as follows:

This document describes a method for extending the scope of the JSON Web Signature (JWS) standard, called JWS/CT.  By combining the detached mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing).  In addition to supporting a consistent data format, this arrangement also simplifies documentation, debugging, and logging.  The ability to embed signed JSON objects in other JSON objects, makes the use of counter-signatures straightforward.

The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large ecosystems that needs digital signatures for plain text JSON data, meaning where the JSON data is not base64 encoded. This ID provides a solution using existing IETF RFCs to make this work. Further, this work looks to be adopted by many groups and organizations from financial services, threat intelligence, and incident response.

We are not sure what direction would be best for this work in the IETF, should we send to the ISE for publication or do you want to create a working group. Ultimately there is a lot of work that could be done in this space to meet the needs of the market. We would be happy with releasing these IDs for ISE publication, or for creating a working group to move them forward. It is just important to note that the market is in desperate need of these solutions. If you want to take it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct

Thanks
Bret

--

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
--------------2LurtlQsQhRwHdctf4Ws9n0f-- From nobody Wed Apr 28 02:00:20 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FFA3A2102; Wed, 28 Apr 2021 02:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG2fS327xRHc; Wed, 28 Apr 2021 02:00:15 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 C31273A2100; Wed, 28 Apr 2021 02:00:14 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 26-20020a05600c22dab029013efd7879b8so6819542wmg.0; Wed, 28 Apr 2021 02:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AnzUbNxb5tujKdkXBudu1u/IXBIzwS0gNOhT+HnKzPQ=; b=ZdC6piseFOw/QESRPtr4AEnxiZ+WxXVoeExtM08B9Ue+jmswHV7t+XL7KpCswa8bIn e1Qwj9jhC7+pOjQ2CEmssWaIYWBvrRt1LpyZKRt3jetPxImsjyuRfsUVwyOLsRmeJ4Q7 LXYKyHMJghUUctZxhq8lW1WbhxqI6ZRn9uCPjzAuGzzADQtENvky7qAvcpuT4iD32KP4 +sZaj6O9n2gHdH7+X27lURdQe5KUn29t68XW4sRe+BJcjWEt2Ia3dpQYL20PKif+GiH0 Et26GtYreBq9vvA9Lz9RUNN67gMuGxvvrkV1xeIg6QHDEGWENmfEGGiz4/9JImvgID2m 57rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AnzUbNxb5tujKdkXBudu1u/IXBIzwS0gNOhT+HnKzPQ=; b=ANe+LsVw6ZHFw6gg03kH+4W2DgkWW0wknmMhZdiVGCzM0f2yAjw01pT/l3BNT5V3wf BOZ8pqG3LmnQ0mH8emSqeOrP4w8aGyWA0TyVFY5EqVFuS3WI9/3thdmNbdHTd81MXY1C n//CMulQh49GjYtzTBHYjoMXgEPTbcJ6lJxt4NyyNECYk8E8/GzbG6bWcXRHS2yArQls UwyoUIlRfEBZilwysKYDVa429Ga3C3PmZ6FbKd2AgUvl/YoGMfI4lQwn5JGHCUTJygMV hTh9jaMzxtyzqxvUqWz0sQYYdZIjj8SusO/CEYEu+Z/v8c0fSgRcfrGE8m2k03rZnIkW DAQQ== X-Gm-Message-State: AOAM531ZtMWI8+ciIm8s4cDVFl4CvF0YTyfgR1ij7p4ewsDV1gkYnmYK wWWrSIEObRPfE6aeWbM+xkg= X-Google-Smtp-Source: ABdhPJxJTKzpX1hhkYmixGh4ZMiDrlS6BVDv7nFDlEDWojXG1jqW9vSZ8Zn/K4DTAW8SPdzNZPxHbA== X-Received: by 2002:a7b:c05a:: with SMTP id u26mr3140166wmc.172.1619600408064; Wed, 28 Apr 2021 02:00:08 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id d5sm7256303wrv.43.2021.04.28.02.00.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Apr 2021 02:00:07 -0700 (PDT) From: Anders Rundgren To: Stefan Santesson Cc: art@ietf.org, IETF SecDispatch , DISPATCH , rfc-ise@rfc-editor.org References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> Message-ID: <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> Date: Wed, 28 Apr 2021 11:00:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] [Secdispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 09:00:20 -0000 On 2021-04-28 8:52, Stefan Santesson wrote: > How is this different/better than implementing RFC 7797 and apply the header b64=false in order to carry plaintext JSON in the payload? Good question! Apart from the fact that the data becomes embedded in the JWS signature container (=changing the structure), you cannot really put JSON there: https://tools.ietf.org/html/rfc7797#section-5.2 My guess that the only real-world use of this option is to save an internal-only (but technically redundant) Base64Url-operation for truly detached data, be it it JSON, PNG, etc. JWS/CT was designed for signing JSON Objects ({}), and let them remain as such. Thanx, Anders > > /Stefan > > > On 2021-04-28 04:29, Bret Jordan wrote: >> Luckily this time we have RFC8785 that solves the canonicalization problem for JSON. >> >> Bret >> >> Sent from my Commodore 64 >> >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 >> >>> On Apr 27, 2021, at 7:39 PM, Dick Hardt wrote: >>> >>>  >>> I am supportive of this work, and would also be willing to work towards a PS. I am seeing rapid growth in the demand to embed JWS in JWS. >>> >>> Given my experience with XML-DSig (see below) making it more XML-DSig like does not sound like a good thing. >>> >>> For any interested in some JWT history, when we were brewing up what became OAuth 2.0, we did not want to tie a token format to the implementation as many deployments had their own proprietary token formats -- but we knew new deployments would benefit from standardizing a token. >>> >>> Our requirements were: >>> - URL safe (access tokens at the time were often passed as a query parameter -- I know, not the best idea, but working with what people wanted) >>> - HTTP header safe >>> - richer than name / value pairs >>> >>> Options we considered: >>> ASN.1 - the 60s are calling and want their data back >>> XML-DSig - not URL safe, large size, and I personally had many scars canonicalizing XML. (An earlier company of mine had a contract to build XML-DSig libraries for a few languages) >>> JSON was becoming very cool at that time, and with base 64 URL safe encoding the string, it was URL safe, and treating the JSON text as binary dealt with the canonicalization concerns -- and JSON canonicalization did not exist. >>> >>> Using a dot as the separator between header, payload, and signature made it easy to parse. The dot was URL safe, but not in the base 64 set. >>> >>> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >>> >>> /Dick >>> >>> >>> >>> >>> ᐧ >>> >>> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan wrote: >>> >>> Dear Dispatch, >>> >>> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for your consideration. This document describes how to use JWS and JCS to create plain-text JSON signatures. The abstract reads as follows: >>> >>> This document describes a method for extending the scope of the JSON Web Signature (JWS) standard, called JWS/CT.  By combining the detached mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing).  In addition to supporting a consistent data format, this arrangement also simplifies documentation, debugging, and logging.  The ability to embed signed JSON objects in other JSON objects, makes the use of counter-signatures straightforward. >>> >>> The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ >>> >>> As you know there are large ecosystems that needs digital signatures for plain text JSON data, meaning where the JSON data is not base64 encoded. This ID provides a solution using existing IETF RFCs to make this work. Further, this work looks to be adopted by many groups and organizations from financial services, threat intelligence, and incident response. >>> >>> We are not sure what direction would be best for this work in the IETF, should we send to the ISE for publication or do you want to create a working group. Ultimately there is a lot of work that could be done in this space to meet the needs of the market. We would be happy with releasing these IDs for ISE publication, or for creating a working group to move them forward. It is just important to note that the market is in desperate need of these solutions. If you want to take it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct >>> >>> Thanks >>> Bret >>> >>> -- >>> >>> Sent from my TI-99/4A >>> >>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 >>> _______________________________________________ >>> art mailing list >>> art@ietf.org >>> https://www.ietf.org/mailman/listinfo/art >>> >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Apr 28 02:21:22 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6CD3A21B6; Wed, 28 Apr 2021 02:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 RSLzxYa5FP9h; Wed, 28 Apr 2021 02:21:14 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110066.outbound.protection.outlook.com [40.107.11.66]) (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 0611C3A21E4; Wed, 28 Apr 2021 02:21:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S9bcuZlzV7jisr31RKXbI9fU2PhEeMOk4gawqcTH6YV5UK+x4FkCdIcFmI7YnO9kPwSjT6ra5vsIbwjBjIoOflxwF9blwqXDjPGXfsMJPf8H96kDGwR9N/hr3rVq9El20H1kFkEZQKpXi6o7n0IuAKiFyhAhCAXYQ/8ur/4hBGGtnOiiaQntagHhJrpzxUkb5+TSMftKMdS6w6aTMUz1Ryo/6/90/TLR6VTe89w5Zyxac+/AViovlhAQfXJUswe7cgdGC6/YGcbT1QcG4UJ9Uno8CIGa65rpj435EfmqKLBu24zrMRnVBgX+972fDtYTaoHVDm8xa3XxQSo4QI0cdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IY+D3HAZtUcjiYW/rWlGxZx3V7M/nyswEH2pGRXCNjI=; b=cvqPHLfQdkCZIuwRpQ9M6r0mkIEYWpIP0u8Z6K6kVQwmy/6unOuDXIME/t0zldROpj95Dg6M7eFImVqwG1cwl75flXth9h8wTbqgzl9hEZLOu9EHVDlNJAtlR6DWfm8S9uTc38GPdxWnMxiC8WjC4rzgxZMxT3af2N5BcsS1BgXIs9dMTXKieOpkf2oGBcpQ8qE7RgAQ7uca1Xg3okiczkDwnvuGYlFHhPFGKt/ekZnrzEJpKRKTbCYc9W71c+KuF+oJlaRRgMKoCm85SXB5Zpi1xbbDpsuIRcWIoJ/22x68jLPM2s+92WjC1uDZQBOv1VmFSVr8Ayuvakyq0H3zng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=manchester.ac.uk; dmarc=pass action=none header.from=manchester.ac.uk; dkim=pass header.d=manchester.ac.uk; arc=none Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:184::9) by LO2P265MB3514.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:1a3::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Wed, 28 Apr 2021 09:21:10 +0000 Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e]) by LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e%7]) with mapi id 15.20.4065.027; Wed, 28 Apr 2021 09:21:10 +0000 From: Stian Soiland-Reyes To: Bret Jordan , Dick Hardt CC: "art@ietf.org" , DISPATCH , "rfc-ise@rfc-editor.org" , IETF SecDispatch Thread-Topic: [art] Plain text JSON digital signatures Thread-Index: AQHXO3n9Ux7vg67F8E+dTqNYh8wUoarJJ3GAgAAOHICAAIPpAA== Date: Wed, 28 Apr 2021 09:21:10 +0000 Message-ID: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> In-Reply-To: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=manchester.ac.uk; x-originating-ip: [2001:8b0:a657:68e3:4d0d:8981:d3ab:c2c3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 443c858e-811a-489f-76b8-08d90a26f64a x-ms-traffictypediagnostic: LO2P265MB3514: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +089s9coeIKCtVAfKJvCPKfoRx3lv2QqxRiJGnFOg4Lj0DBuNz9BwtM5KKlTj/m0XWaQJCyhbvumiuvzqPh+KMn0JsN1BanxyL+BjbjSLYaogyu67GYCsykr+f4P8XKQYix3RkFhGy3tU69yF1HaVy+kEF025KqfL6BNyf1pmsHfNms0WfQbmKRhB2fiIuXEsv2MftpjAf3sz7fTV7JE6+sqNaXoiO2EqYT6L68N5ctZ7cTMfTV9zgjqEmILfOdYeURA2rJkp1SPTRicTjXzmZ65C9lbXuQw2YOKDaax+79npSC1KtE097XuBvQ5E4HunGJxjuZhvl60hizFmz9iqzq3YFivXNx7+rEmb50Bdf0zlcmgkM0LU3DQSZW6qPS5vt7G2p7rGyG42I9PuAv5tveX66JwmqtV5k+lWtO0yOmWgB2LyVxTIqsjrYLqUrclCBUnOMqv7TwEzt9AWW+kz/HbvTmeFo+jTnMkFUoepzlhszBNw7DsJvCJ5OHEY3LXlNrfzU03BvcfJjHMrX+hhOy+plj5hSlKrNtkuwA2crRsEd9LQjZdVYEjqf8BxMNeN9Xg9oHBrbRDs5mRcx/nWguBHUkcj5SSRRrUpuqoQgKbZ6TgTvgwKaQxPRZttnZXRBOk3YtqxrXy8v2DB57SoiyXg8OVf/3GybkeS7djgM6j59tMnPN/TeH4IA96ar/HHdIHNM4wg3Z9X0Pk9ocaWiFiXfP5bwI4PkEHFS5WHg4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(366004)(376002)(346002)(136003)(86362001)(33656002)(8676002)(8936002)(6512007)(21615005)(6506007)(2616005)(122000001)(5660300002)(71200400001)(53546011)(166002)(2906002)(36756003)(76116006)(4326008)(66946007)(110136005)(66476007)(6486002)(66446008)(186003)(64756008)(966005)(478600001)(66556008)(786003)(83380400001)(38100700002)(316002)(54906003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UnZWTzlMSkpNakZoaHNOVFFwdGtMZzk1bUxMcVNlakxkcC9CMzFsZm1oRDhM?= =?utf-8?B?UnhreFQyZW80TVp6aGVaeWF4Z1dmNVVBc1A2ZU9keVo4OWJLYjhRRkdvdFZ2?= =?utf-8?B?M1N1N21UakhjZTJVZ2lCMVVCanRWY0xpdWtTdTRRQUIyM09GbjNxZVZnMTgy?= =?utf-8?B?aFprS3hIZ0xHT1FuNEVwYlh1WC9nQ0MxYU9sNjJFOFZOSEw0NWNndUl0QWhT?= =?utf-8?B?VnlXQ09MbUJuRDh3Y00xZUgzcjJTb2szYzhURUY3K1cwYlJiaDZCNXBUU0F2?= =?utf-8?B?YmIzaXJQanRlMVU4akI5T2t4QUFIMGt0RDRsVFVMWmxQaDFDY291YUg3VjJK?= =?utf-8?B?S3pUcTJFZE1QeGlxRkxmdThxK3BuQTMxaTFsMlphY3J0d2tiaXdReDVpZ2t3?= =?utf-8?B?UkpvZVNRN2R3bW10WDU5czB5YklOeXNMOXlzUFlPUk1LL09iR3NIOWhLRlpG?= =?utf-8?B?aWNxcXBvRFh0a0lqbjVSdFF6SDhBd0t6NkgybHhTK0dRaTV0YmczT0pWcEl0?= =?utf-8?B?VVRDMXVwWnNhUVVQanBSUTBQeDd4YmtrOXo1NUhxMDhRTVV4UnhOeDVtUnBS?= =?utf-8?B?STZib1pGc256eDJuOHFFTUx5OXhyVnNqaWJrbUk3WC9aVU04dHlFOWo3c1lz?= =?utf-8?B?K1pLeVprR2hjb1JybDZtUCtXVVg4NWZGYjFFRVpLS1lOUkxJZXF2U1EzZlZD?= =?utf-8?B?dHJXTTJ2OWpzV2pGRzJhSVkwVGF5N2xINmdySXpGeStEN3ErSnJhbUFqMDdK?= =?utf-8?B?Q0tlVkdoR0NqMUUzYktQWEVIK3RhdnlUYm1WZllLc0RiQ0pGTnZESHRHc3Fz?= =?utf-8?B?TW9aNjVCSzJIQzVub0dJVm40N0N2NmkrQ2QxUWo0dFhrdnB6Z1NGWFp4YkhO?= =?utf-8?B?UGQ2VlVrM01IbVVUYXcyM0thWWwyQmZ6Z3g4YlBlV1NGekpEMHU1QWtGN0tM?= =?utf-8?B?VkRaamRwWlNiTktvSDJRZWZKRWZsdndKZ29zNjJiMFZ0ZThsRTRYU0dWL2xm?= =?utf-8?B?elR3cTB5cjlGNStWcE12Tk9GY0xMTzhxSEtwelVhODd6Sjlnam84UHIyWTI0?= =?utf-8?B?Wm9qVWkra1JaK25XbGluaE5zMkI4dDluYkd3UW1lV2Q1TGtEV0hUdFpTL0c3?= =?utf-8?B?OVpEMkRZZFdoRkg1L3QyQ216a29RelRYQzd4dVgxZGJCN3NGWGV5bU5lQ3JY?= =?utf-8?B?NzA3QTM5TTBCY0gxVENJandQcjlCZHoyUUQ2QU4zN2x1MVBtUnlFMEdtNVd5?= =?utf-8?B?dkpPcmVIZWQ2M0lqbU9NVTdlcCt2aE40RkVMS3I1cUxDbmdSZDRUYjU5UzYv?= =?utf-8?B?MFhwNGZwb01sZFZVV2MxdkhOT09CWkY3WDI1aVdqdlpkTVRNeG5sQ2VGT2xJ?= =?utf-8?B?U0pXNFdWdm9zTEcrSysyU1NCUkRKTldWTWlNQ2pldUZDRThBVEhFMUxaQmNk?= =?utf-8?B?TW4zeWcxVThMQnl2NnlRMnRPVk4wQ3RrOGt2ZHV1ZEZqeFN1S2IrZGZ6N0sv?= =?utf-8?B?bGpSemtBS3RCWUthKzlsVGE1WTJxMDU2b29oT2NhWEpIaDBTelU1UjJYaXh0?= =?utf-8?B?VWsvUVlXSlRCNnhmTEtxYS93a2c4TDF0bk41T3h0dGVpUXhyeWM4T3hpL0hj?= =?utf-8?B?MVdxaW9RYUU0OGZ5Z1lsZU9Nd2xTNzVLV29FS0lrQjNMeUFBZHVRV2JEZmRW?= =?utf-8?B?MkdNeU1xTmF1MGlaK1JkSHpaUnBWdlhRNnIyUVdQMWg3VGp6ZldOaERZUExT?= =?utf-8?B?Ukx4UTlWcENmOXFJOHBPbTl5YUN1azRHVDY4SXJZUm5TL01GcmRXbElMc1ky?= =?utf-8?B?UGViaGpuK0dhbVFqMHFmcWp2TlJNaWlmSWJOVDFJQ2g2ZjVIZUxUV24yVlJm?= =?utf-8?B?TTgyUzR6d3k2THJWaURyeHZoQk9RckxWTHBZK1pNUlFCYmc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FD23AA4B422441629243FAFD9EAD9656manchesteracuk_" MIME-Version: 1.0 X-OriginatorOrg: manchester.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 443c858e-811a-489f-76b8-08d90a26f64a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2021 09:21:10.5710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c152cb07-614e-4abb-818a-f035cfa91a77 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZqETygmx1jNlAWODRrCR2Gv3u4gBCrVuCHh/tQbIHGjqmWd4q7zXZcMjzKijYnm3pju8GgON4+rkaw3XlWnb4cd9j7Immw0ReQYjVo52xFA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB3514 Archived-At: Subject: Re: [dispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 09:21:20 -0000 --_000_FD23AA4B422441629243FAFD9EAD9656manchesteracuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBkcmFmdCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIGFuIGFwcHJvYWNoIHdlIHdvdWxkIGxpa2Ug dG8gdXNlIGluIElFRUUgMjc5MSwgYW5kIGZyb20geW91ciB0ZXh0IGl0IHdpbGwgZml0IHJpZ2h0 IGludG8gb3VyIOKAnGV0YWfigJ0gZmllbGQ8aHR0cHM6Ly9vcGVuc291cmNlLmllZWUub3JnLzI3 OTEtb2JqZWN0L2llZWUtMjc5MS1zY2hlbWEvLS9ibG9iL21hc3Rlci8yNzkxb2JqZWN0Lmpzb24j TDEyOT4gd2hlcmUgd2UgaG9wZSBmb3IgYSBjb25zaXN0ZW50IGhhc2hpbmcgbWVjaGFuaXNtIHRv IGRldGVjdCBjaGFuZ2VzLg0KDQpUaGUgZHJhZnQgc2VlbXMgdG8gYnVpbGQgb24gSlNPTiBXZWIg U2lnbmF0dXJlIChSRkM3NTE1PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3NTE3 Lmh0bWw+KSBhbmQgSlNPTiBXZWIgS2V5IChSRkM3NTE3PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL3JmYy9yZmM3NTE3Lmh0bWw+KSwgYnV0IHRoZSAzLjEuMyBpcyBhIGJpdCB0b28gYnJpZWYg Zm9yIHJlYWRlcnMgbmV3IHRvIHRoZXNlIHN0YW5kYXJkcywgcGVyaGFwcyBnaXZlIGEgYnJpZWYg c3VtbWFyeSBmb3IgdGhpcyBleGFtcGxlLCBlc3BlY2lhbGx5IGFzIFJGQzc1MTcgaXMgcXVpdGUg Y29tcHJlaGVuc2l2ZSB3aXRoIG1hbnkgb3B0aW9ucz8NCg0KSW4gcGFydGljdWxhciBpdCBpcyB1 bmNsZWFyIGlmIHRoZSBKV1MgSGVhZGVyIGFsc28gbmVlZHMgdG8gYmUgSlNPTiBjYW5vbmljYWxp emVkIOKAkyB3aGljaCBtYXkgYmUgYSBnb29kIGlkZWEgZm9yIGNvbnNpc3RlbnQg4oCcaGFzaOKA nSBwdXJwb3NlcyBsaWtlIGluIG91ciB1c2UgY2FzZT8NCg0KSGVyZeKAmXMgbXkgcm91Z2ggc3Vn Z2VzdGlvbiDigJMgcHJvYmFibHkgd3JvbmchIE15IGFkZGl0aW9ucyB1bmluZGVudGVkLg0KDQoN CjMuMS4zLiAgR2VuZXJhdGUgYSBKV1MgU3RyaW5nDQoNCg0KDQogICBVc2UgdGhlIHJlc3VsdCBv ZiB0aGUgcHJldmlvdXMgc3RlcCBhcyAiSldTIFBheWxvYWQiIHRvIHRoZSBzaWduYXR1cmUNCg0K ICAgcHJvY2VzcyBkZXNjcmliZWQgaW4gQXBwZW5kaXggRiBvZiBKV1MgW1JGQzc1MTVdLg0KDQoN Cg0KSW4gc2hvcnQgYSBkZXRhY2hlZCBKV1MgaXMgcmVwcmVzZW50ZWQgYXMgdGhlIHN0cmluZyBj b25jYXRlbmF0ZWQgZnJvbQ0KDQoNCg0KICAgICAgQkFTRTY0VVJMKFVURjgoSldTIFByb3RlY3Rl ZCBIZWFkZXIpKSB8fCAnLicgfHwNCg0KICAgICAgfHwgJy4nIHx8DQoNCiAgICAgIEJBU0U2NFVS TChKV1MgU2lnbmF0dXJlKQ0KDQoNCg0KTm90aWNlLCBmb3IgY29tcGFyaXNvbiB3aXRoIHRoZSBK V1MgQ29tcGFjdCBTZXJpYWxpemF0aW9uLA0KDQp0aGF0IHRoZSBKV1MgUGF5bG9hZCBpcyBub3Qg aW5jbHVkZWQgaW4gdGhlIGRldGFjaGVkIEpXUyBTdHJpbmcsDQoNCmJ1dCByZXBsYWNlZCBieSBh biBlbXB0eSBzdHJpbmcuDQoNCg0KDQogICBGb3IgdGhlIGV4YW1wbGUsIHRoZSBKV1MgaGVhZGVy IGlzIGFzc3VtZWQgdG8gYmU6DQoNCg0KDQogICB7ImFsZyI6IkhTMjU2In0NCg0KDQoNClRoZSBh Ym92ZSBleGFtcGxlIGlzIGVxdWFsIHRvIGl0cyBvd24gSkNTIGNhbm9uaWNhbGl6YXRpb24uDQoN CkpTT04gQ2Fub25pY2FsaXphdGlvbiBpcyBub3QgYSByZXF1aXJlbWVudCBmb3IgdGhlDQoNCkpX UyBIZWFkZXIsIGhvd2V2ZXIgdGhpcyBpcyBSRUNPTU1FTkRFRCwgY29tYmluZWQgd2l0aA0KDQph IGZpeGVkIGFsZ29yaXRobSBjaG9pY2UsIGlmIGdlbmVyYXRpbmcgYSBjb25zaXN0ZW50IEpXUy9D VCBzaWduYXR1cmUNCg0KdGhhdCBpcyBzIGFsc28gdG8gYmUgdXNlZCBhcyBhcyBhIGNhbm9uaWNh bCB2ZXJzaW9uIGlkZW50aWZpZXINCg0Kb2YgdGhlIEpTT04gcGF5bG9hZCBjb250ZW50LCBlLmcu IGFzIGEgc3Ryb25nIEVUYWcgKFJGQzcyMzIpLg0KDQoNCg0KVGhlIEpXUyBTaWduYXR1cmUgb2Yg dGhlIGNhbm9uaWNhbGl6ZWQgSlNPTiBwYXlsb2FkLCB1c2luZyB0aGUga2V5DQoNCnNwZWNpZmll ZCBpbiBTZWN0aW9uIDMsIGlzIHRoZSBieXRlcw0KDQoNCg0KNTQgNzUgNDggYjQgMjAgNDIgNmYg YzQgMzkgeDggOGUgM2QgOGEgNjYgYWIgeGUNCg0KZDIgNWUgNGIgMTEgZjYgYjggYjUgMzQgeGUg MWEgOTAgM2YgOTYgNjMgYzMNCg0KDQoNCg0KDQpFbmNvZGluZyBhcyBCYXNlNjQNCg0KDQoNClRo ZSByZXN1bHRpbmcgY29uY2F0ZW5hdGVkIEpXUyBzdHJpbmcgc2hvdWxkIHRoZW4gcmVhZCBhcyBm b2xsb3dzOg0KDQoNCg0KICAgZXlKaGJHY2lPaUpJVXpJMU5pSjkuLlZIVkl0Q0JDYjhRNUNJLTQ5 aW1hckR0SmVTeEgydUxVMERocVFQNVpqdzQNCg0KDQpZb3UgbWF5IHdhbnQgdG8gbW92ZSBteSBF VGFnIHJlY29tbWVuZGF0aW9uIHRvIGFuIGFwcGVuZGl4LCBhcyBJIGRvbuKAmXQgZmVlbCBpdCBm aXRzIHdlbGwgd2hlcmUgSSBwdXQgaXQsIGJ1dCBJIHRoaW5rIGl0IGlzIHdvcnRoIHBvaW50aW5n IG91dC4gQXMgYSB1c2UgY2FzZS4NCg0KSSBkb27igJl0IGtub3cgZW5vdWdoIGFib3V0IFJGQzc1 MTUsIGlzIGl0IHBvc3NpYmxlIHRvIGRvIHNvbWV0aGluZyBsaWtlIHJlZ3VsYXIgU0hBMyBvciB3 b3VsZCBteSBmaW5nZXJwcmludCB1c2UgY2FzZSBuZWVkIHRvIGp1c3QgcHVibGljbHkgZGVjbGFy ZSB0aGUgc2lnbmF0dXJlIGtleSB0byB1c2U/DQoNCg0KLS0NClN0aWFuIFNvaWxhbmQtUmV5ZXMs IFRoZSBVbml2ZXJzaXR5IG9mIE1hbmNoZXN0ZXINCmh0dHBzOi8vd3d3LmVzY2llbmNlbGFiLm9y Zy51ay8NCmh0dHBzOi8vb3JjaWQub3JnLzAwMDAtMDAwMS05ODQyLTk3MTgNCiAgICBQbGVhc2Ug bm90ZSB0aGF0IEkgbWF5IHdvcmsgZmxleGlibHkg4oCTIHdoaWxzdCBpdCBzdWl0cyBtZSB0byBl bWFpbCBub3csDQogICAgSSBkbyBub3QgZXhwZWN0IGEgcmVzcG9uc2Ugb3IgYWN0aW9uIG91dHNp ZGUgb2YgeW91ciBvd24gd29ya2luZyBob3Vycy4NCg0KDQpGcm9tOiBhcnQgPGFydC1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQnJldCBKb3JkYW4gPGpvcmRhbi5pZXRmQGdtYWlsLmNv bT4NCkRhdGU6IFdlZG5lc2RheSwgMjggQXByaWwgMjAyMSBhdCAwMzoyOQ0KVG86IERpY2sgSGFy ZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KQ2M6ICJhcnRAaWV0Zi5vcmciIDxhcnRAaWV0Zi5v cmc+LCBESVNQQVRDSCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+LCAicmZjLWlzZUByZmMtZWRpdG9yLm9y ZyIgPHJmYy1pc2VAcmZjLWVkaXRvci5vcmc+LCBJRVRGIFNlY0Rpc3BhdGNoIDxTZWNkaXNwYXRj aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbYXJ0XSBQbGFpbiB0ZXh0IEpTT04gZGlnaXRhbCBz aWduYXR1cmVzDQoNCkx1Y2tpbHkgdGhpcyB0aW1lIHdlIGhhdmUgUkZDODc4NSB0aGF0IHNvbHZl cyB0aGUgY2Fub25pY2FsaXphdGlvbiBwcm9ibGVtIGZvciBKU09OLg0KDQpCcmV0DQpTZW50IGZy b20gbXkgQ29tbW9kb3JlIDY0DQoNClBHUCBGaW5nZXJwcmludDogNjNCNCBGQzUzIDY4MEEgNkI3 RCAxNDQ3ICBGMkMwIDc0RjggQUNBRSA3NDE1IDAwNTANCg0KDQpPbiBBcHIgMjcsIDIwMjEsIGF0 IDc6MzkgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPiB3cm90ZToNCkkgYW0g c3VwcG9ydGl2ZSBvZiB0aGlzIHdvcmssIGFuZCB3b3VsZCBhbHNvIGJlIHdpbGxpbmcgdG8gd29y ayB0b3dhcmRzIGEgUFMuIEkgYW0gc2VlaW5nIHJhcGlkIGdyb3d0aCBpbiB0aGUgZGVtYW5kIHRv IGVtYmVkIEpXUyBpbiBKV1MuDQoNCkdpdmVuIG15IGV4cGVyaWVuY2Ugd2l0aCBYTUwtRFNpZyAo c2VlIGJlbG93KSBtYWtpbmcgaXQgbW9yZSBYTUwtRFNpZyBsaWtlIGRvZXMgbm90IHNvdW5kIGxp a2UgYSBnb29kIHRoaW5nLg0KDQpGb3IgYW55IGludGVyZXN0ZWQgaW4gc29tZSBKV1QgaGlzdG9y eSwgd2hlbiB3ZSB3ZXJlIGJyZXdpbmcgdXAgd2hhdCBiZWNhbWUgT0F1dGggMi4wLCB3ZSBkaWQg bm90IHdhbnQgdG8gdGllIGEgdG9rZW4gZm9ybWF0IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBhcyBt YW55IGRlcGxveW1lbnRzIGhhZCB0aGVpciBvd24gcHJvcHJpZXRhcnkgdG9rZW4gZm9ybWF0cyAt LSBidXQgd2Uga25ldyBuZXcgZGVwbG95bWVudHMgd291bGQgYmVuZWZpdCBmcm9tIHN0YW5kYXJk aXppbmcgYSB0b2tlbi4NCg0KT3VyIHJlcXVpcmVtZW50cyB3ZXJlOg0KLSBVUkwgc2FmZSAoYWNj ZXNzIHRva2VucyBhdCB0aGUgdGltZSB3ZXJlIG9mdGVuIHBhc3NlZCBhcyBhIHF1ZXJ5IHBhcmFt ZXRlciAtLSBJIGtub3csIG5vdCB0aGUgYmVzdCBpZGVhLCBidXQgd29ya2luZyB3aXRoIHdoYXQg cGVvcGxlIHdhbnRlZCkNCi0gSFRUUCBoZWFkZXIgc2FmZQ0KLSByaWNoZXIgdGhhbiBuYW1lIC8g dmFsdWUgcGFpcnMNCg0KT3B0aW9ucyB3ZSBjb25zaWRlcmVkOg0KQVNOLjEgLSB0aGUgNjBzIGFy ZSBjYWxsaW5nIGFuZCB3YW50IHRoZWlyIGRhdGEgYmFjaw0KWE1MLURTaWcgLSBub3QgVVJMIHNh ZmUsIGxhcmdlIHNpemUsIGFuZCBJIHBlcnNvbmFsbHkgaGFkIG1hbnkgc2NhcnMgY2Fub25pY2Fs aXppbmcgWE1MLiAoQW4gZWFybGllciBjb21wYW55IG9mIG1pbmUgaGFkIGEgY29udHJhY3QgdG8g YnVpbGQgWE1MLURTaWcgbGlicmFyaWVzIGZvciBhIGZldyBsYW5ndWFnZXMpDQoNCkpTT04gd2Fz IGJlY29taW5nIHZlcnkgY29vbCBhdCB0aGF0IHRpbWUsIGFuZCB3aXRoIGJhc2UgNjQgVVJMIHNh ZmUgZW5jb2RpbmcgdGhlIHN0cmluZywgaXQgd2FzIFVSTCBzYWZlLCBhbmQgdHJlYXRpbmcgdGhl IEpTT04gdGV4dCBhcyBiaW5hcnkgZGVhbHQgd2l0aCB0aGUgY2Fub25pY2FsaXphdGlvbiBjb25j ZXJucyAtLSBhbmQgSlNPTiBjYW5vbmljYWxpemF0aW9uIGRpZCBub3QgZXhpc3QuDQoNClVzaW5n IGEgZG90IGFzIHRoZSBzZXBhcmF0b3IgYmV0d2VlbiBoZWFkZXIsIHBheWxvYWQsIGFuZCBzaWdu YXR1cmUgbWFkZSBpdCBlYXN5IHRvIHBhcnNlLiBUaGUgZG90IHdhcyBVUkwgc2FmZSwgYnV0IG5v dCBpbiB0aGUgYmFzZSA2NCBzZXQuDQoNCkFuZCBTaW1wbGUgV2ViIFRva2VucyB3ZXJlIGJvcm4g LS0gdG8gYmUgcmVuYW1lZCBKU09OIFdlYiBUb2tlbnMuDQoNCi9EaWNrDQoNCg0KDQoNCltJbWFn ZSByZW1vdmVkIGJ5IHNlbmRlci5d4ZCnDQoNCk9uIFR1ZSwgQXByIDI3LCAyMDIxIGF0IDg6Mjgg QU0gQnJldCBKb3JkYW4gPGpvcmRhbi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86am9yZGFuLmlldGZA Z21haWwuY29tPj4gd3JvdGU6DQpEZWFyIERpc3BhdGNoLA0KDQpBbmRlcnMgUnVuZGdyZW4sIFNh bXVlbCwgRXJkdG1hbiwgYW5kIEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gYW4gSUQgZm9yIHlvdXIg Y29uc2lkZXJhdGlvbi4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIHVzZSBKV1MgYW5k IEpDUyB0byBjcmVhdGUgcGxhaW4tdGV4dCBKU09OIHNpZ25hdHVyZXMuIFRoZSBhYnN0cmFjdCBy ZWFkcyBhcyBmb2xsb3dzOg0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBmb3Ig ZXh0ZW5kaW5nIHRoZSBzY29wZSBvZiB0aGUgSlNPTiBXZWIgU2lnbmF0dXJlIChKV1MpIHN0YW5k YXJkLCBjYWxsZWQgSldTL0NULiAgQnkgY29tYmluaW5nIHRoZSBkZXRhY2hlZCBtb2RlIG9mIEpX UyB3aXRoIHRoZSBKU09OIENhbm9uaWNhbGl6YXRpb24gU2NoZW1lIChKQ1MpLCBKV1MvQ1QgZW5h YmxlcyBKU09OIG9iamVjdHMgdG8gcmVtYWluIGluIHRoZSBKU09OIGZvcm1hdCBhZnRlciBiZWlu ZyBzaWduZWQgKGFrYSAiQ2xlYXIgVGV4dCIgc2lnbmluZykuICBJbiBhZGRpdGlvbiB0byBzdXBw b3J0aW5nIGEgY29uc2lzdGVudCBkYXRhIGZvcm1hdCwgdGhpcyBhcnJhbmdlbWVudCBhbHNvIHNp bXBsaWZpZXMgZG9jdW1lbnRhdGlvbiwgZGVidWdnaW5nLCBhbmQgbG9nZ2luZy4gIFRoZSBhYmls aXR5IHRvIGVtYmVkIHNpZ25lZCBKU09OIG9iamVjdHMgaW4gb3RoZXIgSlNPTiBvYmplY3RzLCBt YWtlcyB0aGUgdXNlIG9mIGNvdW50ZXItc2lnbmF0dXJlcyBzdHJhaWdodGZvcndhcmQuDQoNClRo ZSBkYXRhIHRyYWNrZXIgcGFnZSBmb3IgdGhpczogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtam9yZGFuLWp3cy1jdC8NCg0KQXMgeW91IGtub3cgdGhlcmUgYXJlIGxhcmdl IGVjb3N5c3RlbXMgdGhhdCBuZWVkcyBkaWdpdGFsIHNpZ25hdHVyZXMgZm9yIHBsYWluIHRleHQg SlNPTiBkYXRhLCBtZWFuaW5nIHdoZXJlIHRoZSBKU09OIGRhdGEgaXMgbm90IGJhc2U2NCBlbmNv ZGVkLiBUaGlzIElEIHByb3ZpZGVzIGEgc29sdXRpb24gdXNpbmcgZXhpc3RpbmcgSUVURiBSRkNz IHRvIG1ha2UgdGhpcyB3b3JrLiBGdXJ0aGVyLCB0aGlzIHdvcmsgbG9va3MgdG8gYmUgYWRvcHRl ZCBieSBtYW55IGdyb3VwcyBhbmQgb3JnYW5pemF0aW9ucyBmcm9tIGZpbmFuY2lhbCBzZXJ2aWNl cywgdGhyZWF0IGludGVsbGlnZW5jZSwgYW5kIGluY2lkZW50IHJlc3BvbnNlLg0KDQpXZSBhcmUg bm90IHN1cmUgd2hhdCBkaXJlY3Rpb24gd291bGQgYmUgYmVzdCBmb3IgdGhpcyB3b3JrIGluIHRo ZSBJRVRGLCBzaG91bGQgd2Ugc2VuZCB0byB0aGUgSVNFIGZvciBwdWJsaWNhdGlvbiBvciBkbyB5 b3Ugd2FudCB0byBjcmVhdGUgYSB3b3JraW5nIGdyb3VwLiBVbHRpbWF0ZWx5IHRoZXJlIGlzIGEg bG90IG9mIHdvcmsgdGhhdCBjb3VsZCBiZSBkb25lIGluIHRoaXMgc3BhY2UgdG8gbWVldCB0aGUg bmVlZHMgb2YgdGhlIG1hcmtldC4gV2Ugd291bGQgYmUgaGFwcHkgd2l0aCByZWxlYXNpbmcgdGhl c2UgSURzIGZvciBJU0UgcHVibGljYXRpb24sIG9yIGZvciBjcmVhdGluZyBhIHdvcmtpbmcgZ3Jv dXAgdG8gbW92ZSB0aGVtIGZvcndhcmQuIEl0IGlzIGp1c3QgaW1wb3J0YW50IHRvIG5vdGUgdGhh dCB0aGUgbWFya2V0IGlzIGluIGRlc3BlcmF0ZSBuZWVkIG9mIHRoZXNlIHNvbHV0aW9ucy4gSWYg eW91IHdhbnQgdG8gdGFrZSBpdCBmb3IgYSBzcGluLCB0aGVyZSBpcyBhIEpXUy9DVCBwbGF5Z3Jv dW5kIGF0OiBodHRwczovL21vYmlsZXBraS5vcmcvandzLWN0DQoNClRoYW5rcw0KQnJldA0KDQot LQ0KDQpTZW50IGZyb20gbXkgVEktOTkvNEENCg0KDQpQR1AgRmluZ2VycHJpbnQ6IDYzQjQgRkM1 MyA2ODBBIDZCN0QgMTQ0NyAgRjJDMCA3NEY4IEFDQUUgNzQxNSAwMDUwDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXJ0IG1haWxpbmcgbGlzdA0KYXJ0 QGlldGYub3JnPG1haWx0bzphcnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FydA0K --_000_FD23AA4B422441629243FAFD9EAD9656manchesteracuk_ Content-Type: text/html; charset="utf-8" Content-ID: <99AA528C020E434CAA34A6916A6BC2AE@GBRP265.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkV1cGhlbWlh IFVDQVMiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDQgMSAyIDIgMSA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Iklvc2V2a2EgVGVybSI7DQoJcGFub3NlLTE6MiAwIDUgOSAzIDAgMCAwIDAg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5o Mw0KCXttc28tc3R5bGUtbmFtZTpoMzt9DQpwLnAxLCBsaS5wMSwgZGl2LnAxDQoJe21zby1zdHls ZS1uYW1lOnAxOw0KCW1hcmdpbjowY207DQoJYmFja2dyb3VuZDp3aGl0ZTsNCglmb250LXNpemU6 OC41cHQ7DQoJZm9udC1mYW1pbHk6Iklvc2V2a2EgVGVybSI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5zMQ0KCXttc28tc3R5bGUtbmFtZTpzMTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5UaGlzIGRyYWZ0IGlzIHdlbGwgd3JpdHRlbiBhbmQgYW4gYXBwcm9hY2ggd2Ugd291bGQgbGlr ZSB0byB1c2UgaW4gSUVFRSAyNzkxLCBhbmQgZnJvbSB5b3VyIHRleHQgaXQgd2lsbCBmaXQgcmln aHQgaW50byBvdXINCjxhIGhyZWY9Imh0dHBzOi8vb3BlbnNvdXJjZS5pZWVlLm9yZy8yNzkxLW9i amVjdC9pZWVlLTI3OTEtc2NoZW1hLy0vYmxvYi9tYXN0ZXIvMjc5MW9iamVjdC5qc29uI0wxMjki Pg0K4oCcZXRhZ+KAnSBmaWVsZDwvYT4gd2hlcmUgd2UgaG9wZSBmb3IgYSBjb25zaXN0ZW50IGhh c2hpbmcgbWVjaGFuaXNtIHRvIGRldGVjdCBjaGFuZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgZHJhZnQgc2VlbXMg dG8gYnVpbGQgb24gSlNPTiBXZWIgU2lnbmF0dXJlICg8YSBocmVmPSJodHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9yZmMvcmZjNzUxNy5odG1sIj5SRkM3NTE1PC9hPikgYW5kIEpTT04gV2ViIEtl eSAoPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3NTE3 Lmh0bWwiPlJGQzc1MTc8L2E+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4pLA0KIGJ1dCB0aGUgMy4xLjMgaXMgYSBiaXQgdG9vIGJyaWVmIGZvciByZWFkZXJzIG5ldyB0 byB0aGVzZSBzdGFuZGFyZHMsIHBlcmhhcHMgZ2l2ZSBhIGJyaWVmIHN1bW1hcnkgZm9yIHRoaXMg ZXhhbXBsZSwgZXNwZWNpYWxseSBhcyBSRkM3NTE3IGlzIHF1aXRlIGNvbXByZWhlbnNpdmUgd2l0 aCBtYW55IG9wdGlvbnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkluIHBhcnRpY3VsYXIgaXQgaXMgdW5jbGVhciBpZiB0aGUg SldTIEhlYWRlciBhbHNvIG5lZWRzIHRvIGJlIEpTT04gY2Fub25pY2FsaXplZCDigJMgd2hpY2gg bWF5IGJlIGEgZ29vZCBpZGVhIGZvciBjb25zaXN0ZW50IOKAnGhhc2jigJ0gcHVycG9zZXMgbGlr ZSBpbiBvdXIgdXNlIGNhc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhlcmXigJlzIG15IHJvdWdoIHN1Z2dlc3Rpb24g4oCT IHByb2JhYmx5IHdyb25nISBNeSBhZGRpdGlvbnMgdW5pbmRlbnRlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+My4xLjMuJm5i c3A7IEdlbmVyYXRlIGEgSldTIFN0cmluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBVc2UgdGhlIHJlc3VsdCBvZiB0aGUg cHJldmlvdXMgc3RlcCBhcyAmcXVvdDtKV1MgUGF5bG9hZCZxdW90OyB0byB0aGUgc2lnbmF0dXJl PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHByb2Nlc3MgZGVzY3JpYmVkIGlu IEFwcGVuZGl4IEYgb2YgSldTIFtSRkM3NTE1XS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JbiBzaG9ydCBhIGRldGFjaGVkIEpXUyBpcyByZXBy ZXNlbnRlZCBhcyB0aGUgc3RyaW5nIGNvbmNhdGVuYXRlZCBmcm9tPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEJBU0U2NFVSTChVVEY4KEpXUyBQcm90ZWN0ZWQgSGVhZGVyKSkgfHwgJy4nIHx8 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHx8 ICcuJyB8fDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBCQVNFNjRVUkwoSldTIFNpZ25hdHVyZSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Ob3RpY2UsIGZvciBjb21wYXJpc29uIHdpdGggdGhl IDxzcGFuIGNsYXNzPSJoMyI+SldTIENvbXBhY3QgU2VyaWFsaXphdGlvbiwgPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGNsYXNzPSJoMyI+dGhhdCB0aGUgSldTIFBheWxvYWQg aXMgbm90IGluY2x1ZGVkIGluIHRoZSBkZXRhY2hlZCBKV1MgU3RyaW5nLCA8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gY2xhc3M9ImgzIj5idXQgcmVwbGFjZWQgYnkgYW4gZW1w dHkgc3RyaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgRm9yIHRoZSBleGFtcGxlLCB0aGUgSldTIGhlYWRl ciBpcyBhc3N1bWVkIHRvIGJlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB7JnF1b3Q7YWxnJnF1b3Q7OiZxdW90O0hTMjU2 JnF1b3Q7fTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPlRoZSBhYm92ZSBleGFtcGxlIGlzIGVxdWFsIHRvIGl0cyBvd24gSkNTIGNhbm9uaWNhbGl6 YXRpb24uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkpTT04gQ2Fub25pY2FsaXphdGlvbiBpcyBu b3QgYSByZXF1aXJlbWVudCBmb3IgdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkpXUyBIZWFk ZXIsIGhvd2V2ZXIgdGhpcyBpcyBSRUNPTU1FTkRFRCwgY29tYmluZWQgd2l0aDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmEgZml4ZWQgYWxnb3JpdGhtIGNob2ljZSwgaWYgZ2VuZXJhdGluZyBhIGNv bnNpc3RlbnQgSldTL0NUIHNpZ25hdHVyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoYXQgaXMg cyBhbHNvIHRvIGJlIHVzZWQgYXMgYXMgYSBjYW5vbmljYWwgdmVyc2lvbiBpZGVudGlmaWVyIDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9mIHRoZSBKU09OIHBheWxvYWQgY29udGVudCwgZS5nLiBh cyBhIHN0cm9uZyBFVGFnIChSRkM3MjMyKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgSldTIFNpZ25hdHVyZSBvZiB0aGUgY2Fub25pY2Fs aXplZCBKU09OIHBheWxvYWQsIHVzaW5nIHRoZSBrZXkgPG86cD48L286cD48L3ByZT4NCjxwcmU+ c3BlY2lmaWVkIGluIFNlY3Rpb24gMywgaXMgdGhlIGJ5dGVzPG86cD48L286cD48L3ByZT4NCjxw IGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+NTQgNzUgNDggYjQgMjAgNDIgNmYgYzQg MzkgeDggOGUgM2QgOGEgNjYgYWIgeGUgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+ZDIgNWUgNGIgMTEgZjYgYjggYjUgMzQgeGUgMWEgOTAg M2YgOTYgNjMgYzM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkVuY29kaW5nIGFzIEJh c2U2NDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PlRoZSByZXN1bHRpbmcgY29uY2F0ZW5hdGVkIEpXUyBzdHJpbmcgc2hvdWxkIHRoZW4gcmVhZCBh cyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBleUpoYkdjaU9pSklVekkxTmlKOS4uVkhWSXRDQkNiOFE1Q0kt NDlpbWFyRHRKZVN4SDJ1TFUwRGhxUVA1Wmp3NDxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5Zb3UgbWF5IHdhbnQgdG8gbW92ZSBteSBFVGFnIHJlY29tbWVuZGF0aW9uIHRvIGFu IGFwcGVuZGl4LCBhcyBJIGRvbuKAmXQgZmVlbCBpdCBmaXRzIHdlbGwgd2hlcmUgSSBwdXQgaXQs IGJ1dCBJIHRoaW5rIGl0IGlzIHdvcnRoIHBvaW50aW5nIG91dC4gQXMgYSB1c2UgY2FzZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SSBkb27igJl0IGtub3cgZW5vdWdoIGFib3V0IFJGQzc1MTUsIGlzIGl0IHBvc3NpYmxlIHRv IGRvIHNvbWV0aGluZyBsaWtlIHJlZ3VsYXIgU0hBMyBvciB3b3VsZCBteSBmaW5nZXJwcmludCB1 c2UgY2FzZSBuZWVkIHRvIGp1c3QgcHVibGljbHkgZGVjbGFyZSB0aGUgc2lnbmF0dXJlIGtleSB0 byB1c2U/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TdGlhbiBT b2lsYW5kLVJleWVzLCBUaGUgVW5pdmVyc2l0eSBvZiBNYW5jaGVzdGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmVzY2ll bmNlbGFiLm9yZy51ay8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL3d3dy5l c2NpZW5jZWxhYi5vcmcudWsvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9vcmNpZC5vcmcvMDAwMC0wMDAxLTk4 NDItOTcxOCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHBzOi8vb3JjaWQub3JnLzAw MDAtMDAwMS05ODQyLTk3MTg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgUGxlYXNlIG5vdGUgdGhhdCBJIG1h eSB3b3JrIGZsZXhpYmx5IOKAkyB3aGlsc3QgaXQgc3VpdHMgbWUgdG8gZW1haWwgbm93LA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0kgZG8gbm90IGV4cGVjdCBhIHJlc3BvbnNlIG9yIGFjdGlvbiBvdXRzaWRlIG9m IHlvdXIgb3duIHdvcmtpbmcgaG91cnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5hcnQgJmx0O2FydC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg QnJldCBKb3JkYW4gJmx0O2pvcmRhbi5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+V2VkbmVzZGF5LCAyOCBBcHJpbCAyMDIxIGF0IDAzOjI5PGJyPg0KPGI+VG86IDwvYj5EaWNr IEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90 O2FydEBpZXRmLm9yZyZxdW90OyAmbHQ7YXJ0QGlldGYub3JnJmd0OywgRElTUEFUQ0ggJmx0O2Rp c3BhdGNoQGlldGYub3JnJmd0OywgJnF1b3Q7cmZjLWlzZUByZmMtZWRpdG9yLm9yZyZxdW90OyAm bHQ7cmZjLWlzZUByZmMtZWRpdG9yLm9yZyZndDssIElFVEYgU2VjRGlzcGF0Y2ggJmx0O1NlY2Rp c3BhdGNoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW2FydF0gUGxhaW4g dGV4dCBKU09OIGRpZ2l0YWwgc2lnbmF0dXJlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkx1 Y2tpbHkgdGhpcyB0aW1lIHdlIGhhdmUgUkZDODc4NSB0aGF0IHNvbHZlcyB0aGUgY2Fub25pY2Fs aXphdGlvbiBwcm9ibGVtIGZvciBKU09OLiZuYnNwOzxicj4NCjxicj4NCkJyZXQmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50IGZyb20gbXkgQ29t bW9kb3JlIDY0PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q R1AgRmluZ2VycHJpbnQ6Jm5ic3A7NjNCNCBGQzUzIDY4MEEgNkI3RCAxNDQ3ICZuYnNwO0YyQzAg NzRGOCBBQ0FFIDc0MTUgMDA1MDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBBcHIgMjcs IDIwMjEsIGF0IDc6MzkgUE0sIERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gc3VwcG9ydGl2ZSBvZiB0aGlzIHdvcmss IGFuZCB3b3VsZCBhbHNvIGJlIHdpbGxpbmcgdG8gd29yayB0b3dhcmRzIGEgUFMuIEkgYW0gc2Vl aW5nIHJhcGlkIGdyb3d0aCBpbiB0aGUgZGVtYW5kIHRvIGVtYmVkIEpXUyBpbiBKV1MuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiBteSBleHBlcmll bmNlIHdpdGggWE1MLURTaWcgKHNlZSBiZWxvdykgbWFraW5nIGl0IG1vcmUgWE1MLURTaWcgbGlr ZSBkb2VzIG5vdCBzb3VuZCBsaWtlIGEgZ29vZCB0aGluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Gb3IgYW55IGludGVyZXN0ZWQmbmJzcDtpbiBzb21lIEpXVCBoaXN0 b3J5LCB3aGVuIHdlIHdlcmUgYnJld2luZyB1cCB3aGF0IGJlY2FtZSBPQXV0aCAyLjAsIHdlIGRp ZCBub3Qgd2FudCB0byB0aWUgYSB0b2tlbiBmb3JtYXQgdG8gdGhlIGltcGxlbWVudGF0aW9uIGFz IG1hbnkgZGVwbG95bWVudHMgaGFkIHRoZWlyIG93biBwcm9wcmlldGFyeSB0b2tlbiBmb3JtYXRz IC0tIGJ1dCB3ZSBrbmV3IG5ldyBkZXBsb3ltZW50cw0KIHdvdWxkIGJlbmVmaXQmbmJzcDtmcm9t IHN0YW5kYXJkaXppbmcgYSB0b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T3VyIHJlcXVpcmVtZW50cyB3ZXJlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBVUkwgc2FmZSAoYWNjZXNz IHRva2VucyBhdCB0aGUgdGltZSB3ZXJlIG9mdGVuIHBhc3NlZCBhcyBhIHF1ZXJ5IHBhcmFtZXRl ciZuYnNwOy0tIEkga25vdywgbm90IHRoZSBiZXN0IGlkZWEsIGJ1dCB3b3JraW5nJm5ic3A7d2l0 aCB3aGF0IHBlb3BsZSB3YW50ZWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIEhUVFAgaGVhZGVyIHNhZmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gcmljaGVyIHRoYW4gbmFtZSAvIHZhbHVl IHBhaXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9wdGlvbnMgd2UgY29uc2lkZXJlZDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFTTi4xIC0gdGhlIDYwcyBhcmUgY2FsbGluZyBhbmQgd2Fu dCB0aGVpciBkYXRhIGJhY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlhNTC1EU2lnIC0gbm90IFVSTCBzYWZlLCBsYXJnZSBzaXplLCBhbmQgSSBw ZXJzb25hbGx5IGhhZCBtYW55IHNjYXJzIGNhbm9uaWNhbGl6aW5nIFhNTC4gKEFuIGVhcmxpZXIg Y29tcGFueSBvZiBtaW5lIGhhZCBhIGNvbnRyYWN0IHRvIGJ1aWxkIFhNTC1EU2lnIGxpYnJhcmll cyBmb3IgYSBmZXcgbGFuZ3VhZ2VzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5KU09OIHdhcyBiZWNvbWluZyB2ZXJ5IGNvb2wgYXQgdGhhdCB0 aW1lLCBhbmQgd2l0aCBiYXNlIDY0IFVSTCBzYWZlIGVuY29kaW5nIHRoZSBzdHJpbmcsIGl0IHdh cyBVUkwgc2FmZSwgYW5kIHRyZWF0aW5nIHRoZSBKU09OIHRleHQgYXMgYmluYXJ5IGRlYWx0IHdp dGggdGhlIGNhbm9uaWNhbGl6YXRpb24gY29uY2VybnMgLS0gYW5kIEpTT04gY2Fub25pY2FsaXph dGlvbiBkaWQgbm90IGV4aXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Vc2luZyBhIGRvdCBhcyB0aGUgc2VwYXJhdG9yJm5ic3A7YmV0d2Vl biBoZWFkZXIsIHBheWxvYWQsIGFuZCBzaWduYXR1cmUgbWFkZSBpdCBlYXN5IHRvIHBhcnNlLiBU aGUgZG90IHdhcyBVUkwgc2FmZSwgYnV0IG5vdCBpbiB0aGUgYmFzZSA2NCBzZXQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBTaW1wbGUg V2ViIFRva2VucyB3ZXJlIGJvcm4gLS0gdG8gYmUgcmVuYW1lZCBKU09OIFdlYiBUb2tlbnMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9EaWNr PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIzMiIgaGVp Z2h0PSIzMiIgc3R5bGU9IndpZHRoOi4zMzMzaW47aGVpZ2h0Oi4zMzMzaW4iIGlkPSJfeDAwMDBf aTEwMjUiIHNyYz0iY2lkOn5XUkQwMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRl ci4iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0V1cGhlbWlhIFVDQVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBcHIg MjcsIDIwMjEgYXQgODoyOCBBTSBCcmV0IEpvcmRhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvcmRh bi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvcmRhbi5pZXRmQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgRGlzcGF0Y2gsPGJyPg0KPGJyPg0KQW5kZXJzIFJ1 bmRncmVuLCBTYW11ZWwsIEVyZHRtYW4sIGFuZCBJIGhhdmUgYmVlbiB3b3JraW5nIG9uIGFuIElE IGZvciB5b3VyIGNvbnNpZGVyYXRpb24uIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byB1 c2UgSldTIGFuZCBKQ1MgdG8gY3JlYXRlIHBsYWluLXRleHQgSlNPTiBzaWduYXR1cmVzLiBUaGUg YWJzdHJhY3QgcmVhZHMgYXMgZm9sbG93czo8YnI+DQo8YnI+DQpUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBhIG1ldGhvZCBmb3IgZXh0ZW5kaW5nIHRoZSBzY29wZSBvZiB0aGUgSlNPTiBXZWIgU2ln bmF0dXJlIChKV1MpIHN0YW5kYXJkLCBjYWxsZWQgSldTL0NULiZuYnNwOyBCeSBjb21iaW5pbmcg dGhlIGRldGFjaGVkIG1vZGUgb2YgSldTIHdpdGggdGhlIEpTT04gQ2Fub25pY2FsaXphdGlvbiBT Y2hlbWUgKEpDUyksIEpXUy9DVCBlbmFibGVzIEpTT04gb2JqZWN0cyB0byByZW1haW4gaW4gdGhl IEpTT04gZm9ybWF0IGFmdGVyDQogYmVpbmcgc2lnbmVkIChha2EgJnF1b3Q7Q2xlYXIgVGV4dCZx dW90OyBzaWduaW5nKS4mbmJzcDsgSW4gYWRkaXRpb24gdG8gc3VwcG9ydGluZyBhIGNvbnNpc3Rl bnQgZGF0YSBmb3JtYXQsIHRoaXMgYXJyYW5nZW1lbnQgYWxzbyBzaW1wbGlmaWVzIGRvY3VtZW50 YXRpb24sIGRlYnVnZ2luZywgYW5kIGxvZ2dpbmcuJm5ic3A7IFRoZSBhYmlsaXR5IHRvIGVtYmVk IHNpZ25lZCBKU09OIG9iamVjdHMgaW4gb3RoZXIgSlNPTiBvYmplY3RzLCBtYWtlcyB0aGUgdXNl IG9mIGNvdW50ZXItc2lnbmF0dXJlcw0KIHN0cmFpZ2h0Zm9yd2FyZC48YnI+DQo8YnI+DQpUaGUg ZGF0YSB0cmFja2VyIHBhZ2UgZm9yIHRoaXM6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWpvcmRhbi1qd3MtY3QvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qb3JkYW4tandzLWN0LzwvYT48YnI+ DQo8YnI+DQpBcyB5b3Uga25vdyB0aGVyZSBhcmUgbGFyZ2UgZWNvc3lzdGVtcyB0aGF0IG5lZWRz IGRpZ2l0YWwgc2lnbmF0dXJlcyBmb3IgcGxhaW4gdGV4dCBKU09OIGRhdGEsIG1lYW5pbmcgd2hl cmUgdGhlIEpTT04gZGF0YSBpcyBub3QgYmFzZTY0IGVuY29kZWQuIFRoaXMgSUQgcHJvdmlkZXMg YSBzb2x1dGlvbiB1c2luZyBleGlzdGluZyBJRVRGIFJGQ3MgdG8gbWFrZSB0aGlzIHdvcmsuIEZ1 cnRoZXIsIHRoaXMgd29yayBsb29rcyB0byBiZSBhZG9wdGVkDQogYnkgbWFueSBncm91cHMgYW5k IG9yZ2FuaXphdGlvbnMgZnJvbSBmaW5hbmNpYWwgc2VydmljZXMsIHRocmVhdCBpbnRlbGxpZ2Vu Y2UsIGFuZCBpbmNpZGVudCByZXNwb25zZS4NCjxicj4NCjxicj4NCldlIGFyZSBub3Qgc3VyZSB3 aGF0IGRpcmVjdGlvbiB3b3VsZCBiZSBiZXN0IGZvciB0aGlzIHdvcmsgaW4gdGhlIElFVEYsIHNo b3VsZCB3ZSBzZW5kIHRvIHRoZSBJU0UgZm9yIHB1YmxpY2F0aW9uIG9yIGRvIHlvdSB3YW50IHRv IGNyZWF0ZSBhIHdvcmtpbmcgZ3JvdXAuIFVsdGltYXRlbHkgdGhlcmUgaXMgYSBsb3Qgb2Ygd29y ayB0aGF0IGNvdWxkIGJlIGRvbmUgaW4gdGhpcyBzcGFjZSB0byBtZWV0IHRoZSBuZWVkcyBvZiB0 aGUgbWFya2V0LiBXZQ0KIHdvdWxkIGJlIGhhcHB5IHdpdGggcmVsZWFzaW5nIHRoZXNlIElEcyBm b3IgSVNFIHB1YmxpY2F0aW9uLCBvciBmb3IgY3JlYXRpbmcgYSB3b3JraW5nIGdyb3VwIHRvIG1v dmUgdGhlbSBmb3J3YXJkLiBJdCBpcyBqdXN0IGltcG9ydGFudCB0byBub3RlIHRoYXQgdGhlIG1h cmtldCBpcyBpbiBkZXNwZXJhdGUgbmVlZCBvZiB0aGVzZSBzb2x1dGlvbnMuIElmIHlvdSB3YW50 IHRvIHRha2UgaXQgZm9yIGEgc3BpbiwgdGhlcmUgaXMgYSBKV1MvQ1QgcGxheWdyb3VuZA0KIGF0 OiA8YSBocmVmPSJodHRwczovL21vYmlsZXBraS5vcmcvandzLWN0IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9tb2JpbGVwa2kub3JnL2p3cy1jdDwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJldDxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+U2VudCBm cm9tIG15IFRJLTk5LzRBPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlBHUCBGaW5nZXJwcmludDombmJzcDs2M0I0IEZD NTMgNjgwQSA2QjdEIDE0NDcgJm5ic3A7RjJDMCA3NEY4IEFDQUUmbmJzcDs3NDE1IDAwNTA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCmFydCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86YXJ0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YXJ0QGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXJ0IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcnQ8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FD23AA4B422441629243FAFD9EAD9656manchesteracuk_-- From nobody Wed Apr 28 02:30:12 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297003A220D for ; Wed, 28 Apr 2021 02:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 OBMWwaHgaTbX for ; Wed, 28 Apr 2021 02:30:02 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (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 A28C23A220C for ; Wed, 28 Apr 2021 02:30:01 -0700 (PDT) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with UTF8SMTP id 402491A9D1ED for ; Wed, 28 Apr 2021 11:29:58 +0200 (CEST) Received: from s934.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with UTF8SMTP id 3065F2E2BE63; Wed, 28 Apr 2021 11:29:58 +0200 (CEST) Received: from s470.loopia.se (unknown [172.22.191.5]) by s934.loopia.se (Postfix) with UTF8SMTP id 2D12E7CEA17; Wed, 28 Apr 2021 11:29:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.22.191.5]) by s470.loopia.se (s470.loopia.se [172.22.190.10]) (amavisd-new, port 10024) with UTF8LMTP id nGYXCeWHaftE; Wed, 28 Apr 2021 11:29:57 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.1.217] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with UTF8SMTPSA id 3AC841CE628B; Wed, 28 Apr 2021 11:29:57 +0200 (CEST) Message-ID: <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> Date: Wed, 28 Apr 2021 11:29:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: Anders Rundgren Cc: DISPATCH , art@ietf.org, IETF SecDispatch , rfc-ise@rfc-editor.org References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> From: Stefan Santesson Organization: 3xA Security AB In-Reply-To: <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] [Secdispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 09:30:07 -0000 RFC 7797 is supported by common open source such as Nimbus and I use it for instances where you obviously do not need a URL safe token. As such it works for JWS but Not for JWT. But It works really well and saves space when URL safeness is not needed. So I guess your answer is that it still encapsulates the signed JSON in the signature, and that the proposal really is about embedding signature in the JSON object being signed (and not about whether the JSON is in plaintext). Could you elaborate why you think it is important to NOT embed signed data in the signature? What is the usecase? /Stefan On 2021-04-28 11:00, Anders Rundgren wrote: > On 2021-04-28 8:52, Stefan Santesson wrote: >> How is this different/better than implementing RFC 7797 and apply the >> header b64=false in order to carry plaintext JSON in the payload? > > Good question! > > Apart from the fact that the data becomes embedded in the JWS > signature container (=changing the structure), you cannot really put > JSON there: > https://tools.ietf.org/html/rfc7797#section-5.2 > > My guess that the only real-world use of this option is to save an > internal-only (but technically redundant) Base64Url-operation for > truly detached data, be it it JSON, PNG, etc. > > JWS/CT was designed for signing JSON Objects ({}), and let them remain > as such. > > Thanx, > Anders > >> >> /Stefan >> >> >> On 2021-04-28 04:29, Bret Jordan wrote: >>> Luckily this time we have RFC8785 that solves the canonicalization >>> problem for JSON. >>> >>> Bret >>> >>> Sent from my Commodore 64 >>> >>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 >>> >>>> On Apr 27, 2021, at 7:39 PM, Dick Hardt wrote: >>>> >>>>  >>>> I am supportive of this work, and would also be willing to work >>>> towards a PS. I am seeing rapid growth in the demand to embed JWS >>>> in JWS. >>>> >>>> Given my experience with XML-DSig (see below) making it more >>>> XML-DSig like does not sound like a good thing. >>>> >>>> For any interested in some JWT history, when we were brewing up >>>> what became OAuth 2.0, we did not want to tie a token format to the >>>> implementation as many deployments had their own proprietary token >>>> formats -- but we knew new deployments would benefit from >>>> standardizing a token. >>>> >>>> Our requirements were: >>>> - URL safe (access tokens at the time were often passed as a query >>>> parameter -- I know, not the best idea, but working with what >>>> people wanted) >>>> - HTTP header safe >>>> - richer than name / value pairs >>>> >>>> Options we considered: >>>> ASN.1 - the 60s are calling and want their data back >>>> XML-DSig - not URL safe, large size, and I personally had many >>>> scars canonicalizing XML. (An earlier company of mine had a >>>> contract to build XML-DSig libraries for a few languages) >>>> JSON was becoming very cool at that time, and with base 64 URL safe >>>> encoding the string, it was URL safe, and treating the JSON text as >>>> binary dealt with the canonicalization concerns -- and JSON >>>> canonicalization did not exist. >>>> >>>> Using a dot as the separator between header, payload, and >>>> signature made it easy to parse. The dot was URL safe, but not in >>>> the base 64 set. >>>> >>>> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >>>> >>>> /Dick >>>> >>>> >>>> >>>> >>>> ᐧ >>>> >>>> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan >>>> wrote: >>>> >>>>     Dear Dispatch, >>>> >>>>     Anders Rundgren, Samuel, Erdtman, and I have been working on >>>> an ID for your consideration. This document describes how to use >>>> JWS and JCS to create plain-text JSON signatures. The abstract >>>> reads as follows: >>>> >>>>     This document describes a method for extending the scope of >>>> the JSON Web Signature (JWS) standard, called JWS/CT.  By >>>> combining the detached mode of JWS with the JSON Canonicalization >>>> Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON >>>> format after being signed (aka "Clear Text" signing).  In addition >>>> to supporting a consistent data format, this arrangement also >>>> simplifies documentation, debugging, and logging.  The ability to >>>> embed signed JSON objects in other JSON objects, makes the use of >>>> counter-signatures straightforward. >>>> >>>>     The data tracker page for this: >>>> https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ >>>> >>>>     As you know there are large ecosystems that needs digital >>>> signatures for plain text JSON data, meaning where the JSON data is >>>> not base64 encoded. This ID provides a solution using existing IETF >>>> RFCs to make this work. Further, this work looks to be adopted by >>>> many groups and organizations from financial services, threat >>>> intelligence, and incident response. >>>> >>>>     We are not sure what direction would be best for this work >>>> in the IETF, should we send to the ISE for publication or do you >>>> want to create a working group. Ultimately there is a lot of work >>>> that could be done in this space to meet the needs of the market. >>>> We would be happy with releasing these IDs for ISE publication, or >>>> for creating a working group to move them forward. It is just >>>> important to note that the market is in desperate need of these >>>> solutions. If you want to take it for a spin, there is a JWS/CT >>>> playground at: https://mobilepki.org/jws-ct >>>> >>>>     Thanks >>>>     Bret >>>> >>>>     -- >>>>     Sent from my TI-99/4A >>>> >>>>     PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 >>>> ACAE 7415 0050 >>>>     _______________________________________________ >>>>     art mailing list >>>>     art@ietf.org >>>>     https://www.ietf.org/mailman/listinfo/art >>>> >>> >>> _______________________________________________ >>> Secdispatch mailing list >>> Secdispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Wed Apr 28 02:52:18 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACFC3A22C8; Wed, 28 Apr 2021 02:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 c0-C1DGLp_Vd; Wed, 28 Apr 2021 02:52:07 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100085.outbound.protection.outlook.com [40.107.10.85]) (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 965BA3A22C7; Wed, 28 Apr 2021 02:52:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UTz4tMHEvYrMl8iP+9pXyogWq9pekSXvz3YHA/m0VdlMEn3aNKQerqq0iiFOIXAdZFXJdlXOsNwEoMH+qgErdLp8dqoynhXt6F/JzxyE7it60XQGQZXTJCQt+VfKR0xmilJ73cHWX9gbE5JKS1g6UDhYE8tz6MMSDeIohxi+iW+1fr+B7Gg8jTdfY9SuWnPkxwCY6g35nDnW4YbU9Ipj1vVZT1/k8LcsqceoTb4r+2AHkFQ2lBMmEEHbINBqsZGvXymCCnRdV3PIF2WykK8DS3ueaBl4C4HslQUETbnxZ3gcbCR7nz0hgCDzUyLdQ7zfiqwrKr77U8fGUwdpfxmxKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+dzmsmH8ccztDupvbSZ4ewlgfagGHkEQbIa5m/JVpAw=; b=kLQ+ogbAXcOX31NvGVFlTMsWnwLBoGe+GdCQEtT9apucpbDuKY01HnA0l5wl5/66gAD16HV+CX2jXtvsfPJCJ9r/0Vec2y9dnKh48QOohjKmi8UNFtjyhy8eurHIt/Lwaum+ZEH9STozmZpQh4Xu7eLqDFqsQL2NpwnGJTYPtn5ksbmNmedxkBacFGcVroNWe1D2r8rU7hW74dnhLoNf+k9v1Ev7GxjKrrBWdbZNDMlk8DknjIOQgCKwqUUsBvQ0Gikvbnf4pgJAq+FKhms51UpYymuYkKYluEKgaR6DewwQZQzGpDDDJmgKCvWy690nfrmDT8gbnh+rldIltAiRSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=manchester.ac.uk; dmarc=pass action=none header.from=manchester.ac.uk; dkim=pass header.d=manchester.ac.uk; arc=none Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:184::9) by LO2P265MB3134.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:166::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Wed, 28 Apr 2021 09:52:03 +0000 Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e]) by LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e%7]) with mapi id 15.20.4065.027; Wed, 28 Apr 2021 09:52:03 +0000 From: Stian Soiland-Reyes To: Bret Jordan , Dick Hardt CC: "art@ietf.org" , IETF SecDispatch , DISPATCH , "rfc-ise@rfc-editor.org" Thread-Topic: [art] Plain text JSON digital signatures Thread-Index: AQHXO3n9Ux7vg67F8E+dTqNYh8wUoarJJ3GAgAAOHICAAIPpAIAACKAA Date: Wed, 28 Apr 2021 09:52:02 +0000 Message-ID: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=manchester.ac.uk; x-originating-ip: [2001:8b0:a657:68e3:4d0d:8981:d3ab:c2c3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f59d230a-262e-4ae0-2520-08d90a2b4660 x-ms-traffictypediagnostic: LO2P265MB3134: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d4B1f1LIGGhcEPO2VHzKAuz18R1oB1egQCoMb4pMcr4hjYOncZRoiNihB3BnNLDQGtijLtECL14RvKSCoygPlzOtrykqNppz+KZ2HQfKbgmm8e4Rbr8vn6PjOIn8KGTsw92YJXdPwHuB+e1N/327/2zPaeHdy3d8fAokXNzxSwF/LL5VQzyg1bo5okjL/MDWlvC0V6q73e+SpNwJEPoYxHCag6wN7DGljlxk0idIoqRxBaGAfmA1/6Y+PuOvIGHzA76/b7iLCHXfHvooPax75CPfAjEcWMclXRTIazKaTfUY/dOG16fqbm3L52m4BnGeZf2ECSGmxVSTYptdCG8P5s3ERI/aTFk3/dwcqcd2K2hk/JeJwn8r50kgseNkyKlpGirT3Knv9OykFp3JHVGOBZjMUqPJQP+YURZwnLFfrHbo7NMKVx+0t03SRLrPoe73WTG7zjkgAM/gnwQGILpnAeohQNWEpYyYnTP8ydZBM9YoTiAgmHZ7PSxyv/xs8IZ3N671O3MIakKZ7iRSLFhxjSM6eGK6zDiTWRYLpnEBHKgp4sVdexAPepIf4og+oHjIFE2xa3DXrm2K251sJK0qwC39a2SWE7L8Bg49YStNNqql1Rip7R7DS2jgNX3nEvxKnf/i65K5kelih7W8H0wR1FhPFuaIWDgiIRqzhacPVPqgLB9T+ewBEerMmtJz5LO9aB1D6CyEtalHy1sVA/1hIPtdH4LhSuiUl7UdWjAhzDk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(396003)(136003)(39860400002)(478600001)(4326008)(6512007)(166002)(83380400001)(8676002)(86362001)(38100700002)(33656002)(21615005)(36756003)(122000001)(2906002)(186003)(66446008)(2616005)(786003)(316002)(53546011)(71200400001)(6506007)(66946007)(66476007)(64756008)(8936002)(76116006)(54906003)(6486002)(110136005)(5660300002)(966005)(66556008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WHN6NTU4QmswanFUa3RjYUN5Ni92UDdhblJ4dWt4WjZkUCtVcjRFZGNUbXdy?= =?utf-8?B?R09QcTBlZ2ZwU0dRS0FkNU8veWw5VExzaXJXU2pPUXdpQnA3c2RhNHpwYUQy?= =?utf-8?B?bHhHTmoyQ1IvYzE2WjdvQzhpWkN4V0dha25zVlRzQ0hZTWdQNnFaT1FGQUMr?= =?utf-8?B?WUNSUzB3MHZYMW53a2VLUXBwaWFJd3lYdVF4KzIzU2ZWTHBnNWN5cjVvSUZC?= =?utf-8?B?MlEyd2g1VDg1bTkxNkFlZkFrT3R1WEJNQWx5SDA0TWxXYlhwVXVUNVM0dVlT?= =?utf-8?B?anRVcjA5UFBMdklMa21Ec0paU0xrLzllQzZwS25LaGR0M29FQ0liaEFnSitG?= =?utf-8?B?bVB0ZkJzTUZEeFdRRWtJN3ZZTWJaenRJVm9QT1MxSmlJSVowZlY3RHFwRGVv?= =?utf-8?B?Ti96WVphaUV0T3c2K21BWWVwc2xweW9wSGN3MWttQXJyYlhZY1ltdXJIeEUx?= =?utf-8?B?dGY1WFVGVWJSUmRRWndDQUE4WEJ2SGpMSktWRFpDSy9sMmFGRThtczhDWmFI?= =?utf-8?B?dmsxRU5MK3R6MmhnZ2ViaURMOWlDcFJRdlFiVm8wem5JRVJGQlNLRGhpZmNK?= =?utf-8?B?NWkvRm0rWk1oTEZaaGxzcVNNTjhXcTZEMHdoNVNZbURnTWxManNqVURVK2Zn?= =?utf-8?B?QXpSb2pSR2hMbG1MMUFrWHFRU29WM3lETzQ3ZXU3ZU40a0JhMlRaRTNwWTB6?= =?utf-8?B?ZTZwdWtjei9mME1tTDRPQUF4UHQzUHNnSDRBMmpIS2IwWVRCQmNWVFBpQi80?= =?utf-8?B?bkphL1JyVG5iOTAzcHlNbnhiV0FiVk1hdmh1QkRoZWszVG40UWNWSDE3amNB?= =?utf-8?B?VVI0U0xiM05wN1hVWEpoTi9DVis4YTZMMmk2NVN5TGRNOFMySjkrNGY0Vzll?= =?utf-8?B?QjU1VlZBNm5yMUpyUGdUL2k3b0xQMTBCWEdIL3B0c0t0NHpZUW9YU2FNc3k2?= =?utf-8?B?K1crbmtuQ0hYWGpYZ0pKUldPc1JoMU9oSlRRd3RFajVZR0RkTXl6d0ljdHNj?= =?utf-8?B?Q1FUbEJxOC9yMk9HR2xwWVJFM2szZklKYUF0eXZoZGw2THBHSDEzaFpDRzNH?= =?utf-8?B?d1VQNUFjZlQxcm44UDNYNmRSOWVJNVcxaTBoQWdQSm1OQ0VTZE5LcStFY2Vo?= =?utf-8?B?M3FrNzlFYkVsL1lYUDlaWmYzMlp6WEY3b0xEN3psMDF1dVRjTE5VekIzN0Ri?= =?utf-8?B?b3M2T2FQMGt5cVVCWkRQTThtTUVGbGN3SjBZSW9IUm9TNStFODJINFpTdjJu?= =?utf-8?B?QUNjU2JtOWhGQzJKajJ1WXNFVWxuRmVBOXJnd3BVWDMxd0NGYWJHT1R1Smdr?= =?utf-8?B?c3RTY3MxLzcwZHA3cUhwS2gydUgyUkZCczdGcTF5RlIyVm52ZGlBMitqM014?= =?utf-8?B?ZGhpZEFLMGo5dm9BUi9CSXAwWGh0U0owV3FFVmhnbkI3VkhYazFMbW1jWW5T?= =?utf-8?B?cHhkUitTTGJPUGhjcDV5UlJGc3N3YjIvSHpOVHlMV1VmQ3lMTFpLMXhsN2N2?= =?utf-8?B?aUVaa1QybUxuMU9tVnVsSEZhMlJncW9mc0hObVUyd0NpbkhaVi9keEh2b2VC?= =?utf-8?B?WktuNERnTWxiUEVwcStNYnV2OE4ySXpxd0VQb0k2Z1padGtQZnJ0TncwRytX?= =?utf-8?B?U0gwYXpUNWgrb0FLWUM1ZUhPWVlERXJhZnZVTFgxMStZQzcxYUJSU29BQVhW?= =?utf-8?B?K05pRDIrMGVtWktDZUNzdHMrelpxY0VTR2lLMy9YZTQ1aUVuTVJPc3pzR3Bl?= =?utf-8?B?WVVUckNJRzJXbnMzdFM0aldNN0sreXJmNmN4OWhNbmVyVWpkSkE3V3VGOGpu?= =?utf-8?B?QUo0WlFrZ0M4UHFacnNFWjhuMHA4bHFCUUhKOHZ2dXlQWG5NaTJyajNiQjVm?= =?utf-8?B?aDJ0Q1VnWWlvNXVjRUVNbkkvdUFubVBObkV1WlRnU2FHZFE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CA685270A83449AF993A75F0D70308DBmanchesteracuk_" MIME-Version: 1.0 X-OriginatorOrg: manchester.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f59d230a-262e-4ae0-2520-08d90a2b4660 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2021 09:52:02.9416 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c152cb07-614e-4abb-818a-f035cfa91a77 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qXcBMOpPYOXCnjC7s6kVJCTHMipiXS5v0E6GiBLKP4VmhHxtTj6f3wJeweucqOrcHVBLFgd9yU0DUdQpMBFrLaVmRL3lcK2yRVSAKREMZiM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB3134 Archived-At: Subject: Re: [dispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 09:52:13 -0000 --_000_CA685270A83449AF993A75F0D70308DBmanchesteracuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCmIEkgdGhpbmsgSSBnb3QgaXQgd3JvbmcgYmVsb3csIGFzIHRoZSBKV1MgU2lnbmF0dXJlIGlm IEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0IGFsc28gbmVlZHMgdG8gaW5jbHVkZSB0aGUgSldTIGhl YWRlcj8NCg0KUGVyaGFwcyB0aGlzIGlzIHdoeSBpdCBuZWVkcyB0byBiZSBjbGFyaWZpZWQgaGVy ZSEg8J+Yig0KDQotLQ0KU3RpYW4gU29pbGFuZC1SZXllcywgVGhlIFVuaXZlcnNpdHkgb2YgTWFu Y2hlc3Rlcg0KaHR0cHM6Ly93d3cuZXNjaWVuY2VsYWIub3JnLnVrLw0KaHR0cHM6Ly9vcmNpZC5v cmcvMDAwMC0wMDAxLTk4NDItOTcxOA0KICAgIFBsZWFzZSBub3RlIHRoYXQgSSBtYXkgd29yayBm bGV4aWJseSDigJMgd2hpbHN0IGl0IHN1aXRzIG1lIHRvIGVtYWlsIG5vdywNCiAgICBJIGRvIG5v dCBleHBlY3QgYSByZXNwb25zZSBvciBhY3Rpb24gb3V0c2lkZSBvZiB5b3VyIG93biB3b3JraW5n IGhvdXJzLg0KDQoNCkZyb206IGFydCA8YXJ0LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBTdGlhbiBTb2lsYW5kLVJleWVzIDxzb2lsYW5kLXJleWVzQG1hbmNoZXN0ZXIuYWMudWs+DQpE YXRlOiBXZWRuZXNkYXksIDI4IEFwcmlsIDIwMjEgYXQgMTA6MjINClRvOiBCcmV0IEpvcmRhbiA8 am9yZGFuLmlldGZAZ21haWwuY29tPiwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+ DQpDYzogImFydEBpZXRmLm9yZyIgPGFydEBpZXRmLm9yZz4sIElFVEYgU2VjRGlzcGF0Y2ggPFNl Y2Rpc3BhdGNoQGlldGYub3JnPiwgRElTUEFUQ0ggPGRpc3BhdGNoQGlldGYub3JnPiwgInJmYy1p c2VAcmZjLWVkaXRvci5vcmciIDxyZmMtaXNlQHJmYy1lZGl0b3Iub3JnPg0KU3ViamVjdDogUmU6 IFthcnRdIFBsYWluIHRleHQgSlNPTiBkaWdpdGFsIHNpZ25hdHVyZXMNCg0KVGhpcyBkcmFmdCBp cyB3ZWxsIHdyaXR0ZW4gYW5kIGFuIGFwcHJvYWNoIHdlIHdvdWxkIGxpa2UgdG8gdXNlIGluIElF RUUgMjc5MSwgYW5kIGZyb20geW91ciB0ZXh0IGl0IHdpbGwgZml0IHJpZ2h0IGludG8gb3VyIOKA nGV0YWfigJ0gZmllbGQ8aHR0cHM6Ly9vcGVuc291cmNlLmllZWUub3JnLzI3OTEtb2JqZWN0L2ll ZWUtMjc5MS1zY2hlbWEvLS9ibG9iL21hc3Rlci8yNzkxb2JqZWN0Lmpzb24jTDEyOT4gd2hlcmUg d2UgaG9wZSBmb3IgYSBjb25zaXN0ZW50IGhhc2hpbmcgbWVjaGFuaXNtIHRvIGRldGVjdCBjaGFu Z2VzLg0KDQpUaGUgZHJhZnQgc2VlbXMgdG8gYnVpbGQgb24gSlNPTiBXZWIgU2lnbmF0dXJlIChS RkM3NTE1PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3NTE3Lmh0bWw+KSBhbmQg SlNPTiBXZWIgS2V5IChSRkM3NTE3PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3 NTE3Lmh0bWw+KSwgYnV0IHRoZSAzLjEuMyBpcyBhIGJpdCB0b28gYnJpZWYgZm9yIHJlYWRlcnMg bmV3IHRvIHRoZXNlIHN0YW5kYXJkcywgcGVyaGFwcyBnaXZlIGEgYnJpZWYgc3VtbWFyeSBmb3Ig dGhpcyBleGFtcGxlLCBlc3BlY2lhbGx5IGFzIFJGQzc1MTcgaXMgcXVpdGUgY29tcHJlaGVuc2l2 ZSB3aXRoIG1hbnkgb3B0aW9ucz8NCg0KSW4gcGFydGljdWxhciBpdCBpcyB1bmNsZWFyIGlmIHRo ZSBKV1MgSGVhZGVyIGFsc28gbmVlZHMgdG8gYmUgSlNPTiBjYW5vbmljYWxpemVkIOKAkyB3aGlj aCBtYXkgYmUgYSBnb29kIGlkZWEgZm9yIGNvbnNpc3RlbnQg4oCcaGFzaOKAnSBwdXJwb3NlcyBs aWtlIGluIG91ciB1c2UgY2FzZT8NCg0KSGVyZeKAmXMgbXkgcm91Z2ggc3VnZ2VzdGlvbiDigJMg cHJvYmFibHkgd3JvbmchIE15IGFkZGl0aW9ucyB1bmluZGVudGVkLg0KDQoNCjMuMS4zLiAgR2Vu ZXJhdGUgYSBKV1MgU3RyaW5nDQoNCg0KDQogICBVc2UgdGhlIHJlc3VsdCBvZiB0aGUgcHJldmlv dXMgc3RlcCBhcyAiSldTIFBheWxvYWQiIHRvIHRoZSBzaWduYXR1cmUNCg0KICAgcHJvY2VzcyBk ZXNjcmliZWQgaW4gQXBwZW5kaXggRiBvZiBKV1MgW1JGQzc1MTVdLg0KDQoNCg0KSW4gc2hvcnQg YSBkZXRhY2hlZCBKV1MgaXMgcmVwcmVzZW50ZWQgYXMgdGhlIHN0cmluZyBjb25jYXRlbmF0ZWQg ZnJvbQ0KDQoNCg0KICAgICAgQkFTRTY0VVJMKFVURjgoSldTIFByb3RlY3RlZCBIZWFkZXIpKSB8 fCAnLicgfHwNCg0KICAgICAgfHwgJy4nIHx8DQoNCiAgICAgIEJBU0U2NFVSTChKV1MgU2lnbmF0 dXJlKQ0KDQoNCg0KTm90aWNlLCBmb3IgY29tcGFyaXNvbiB3aXRoIHRoZSBKV1MgQ29tcGFjdCBT ZXJpYWxpemF0aW9uLA0KDQp0aGF0IHRoZSBKV1MgUGF5bG9hZCBpcyBub3QgaW5jbHVkZWQgaW4g dGhlIGRldGFjaGVkIEpXUyBTdHJpbmcsDQoNCmJ1dCByZXBsYWNlZCBieSBhbiBlbXB0eSBzdHJp bmcuDQoNCg0KDQogICBGb3IgdGhlIGV4YW1wbGUsIHRoZSBKV1MgaGVhZGVyIGlzIGFzc3VtZWQg dG8gYmU6DQoNCg0KDQogICB7ImFsZyI6IkhTMjU2In0NCg0KDQoNClRoZSBhYm92ZSBleGFtcGxl IGlzIGVxdWFsIHRvIGl0cyBvd24gSkNTIGNhbm9uaWNhbGl6YXRpb24uDQoNCkpTT04gQ2Fub25p Y2FsaXphdGlvbiBpcyBub3QgYSByZXF1aXJlbWVudCBmb3IgdGhlDQoNCkpXUyBIZWFkZXIsIGhv d2V2ZXIgdGhpcyBpcyBSRUNPTU1FTkRFRCwgY29tYmluZWQgd2l0aA0KDQphIGZpeGVkIGFsZ29y aXRobSBjaG9pY2UsIGlmIGdlbmVyYXRpbmcgYSBjb25zaXN0ZW50IEpXUy9DVCBzaWduYXR1cmUN Cg0KdGhhdCBpcyBzIGFsc28gdG8gYmUgdXNlZCBhcyBhcyBhIGNhbm9uaWNhbCB2ZXJzaW9uIGlk ZW50aWZpZXINCg0Kb2YgdGhlIEpTT04gcGF5bG9hZCBjb250ZW50LCBlLmcuIGFzIGEgc3Ryb25n IEVUYWcgKFJGQzcyMzIpLg0KDQoNCg0KVGhlIEpXUyBTaWduYXR1cmUgb2YgdGhlIGNhbm9uaWNh bGl6ZWQgSlNPTiBwYXlsb2FkLCB1c2luZyB0aGUga2V5DQoNCnNwZWNpZmllZCBpbiBTZWN0aW9u IDMsIGlzIHRoZSBieXRlcw0KDQoNCg0KNTQgNzUgNDggYjQgMjAgNDIgNmYgYzQgMzkgeDggOGUg M2QgOGEgNjYgYWIgeGUNCg0KZDIgNWUgNGIgMTEgZjYgYjggYjUgMzQgeGUgMWEgOTAgM2YgOTYg NjMgYzMNCg0KDQoNCg0KDQpFbmNvZGluZyBhcyBCYXNlNjQNCg0KDQoNClRoZSByZXN1bHRpbmcg Y29uY2F0ZW5hdGVkIEpXUyBzdHJpbmcgc2hvdWxkIHRoZW4gcmVhZCBhcyBmb2xsb3dzOg0KDQoN Cg0KICAgZXlKaGJHY2lPaUpJVXpJMU5pSjkuLlZIVkl0Q0JDYjhRNUNJLTQ5aW1hckR0SmVTeEgy dUxVMERocVFQNVpqdzQNCg0KDQpZb3UgbWF5IHdhbnQgdG8gbW92ZSBteSBFVGFnIHJlY29tbWVu ZGF0aW9uIHRvIGFuIGFwcGVuZGl4LCBhcyBJIGRvbuKAmXQgZmVlbCBpdCBmaXRzIHdlbGwgd2hl cmUgSSBwdXQgaXQsIGJ1dCBJIHRoaW5rIGl0IGlzIHdvcnRoIHBvaW50aW5nIG91dC4gQXMgYSB1 c2UgY2FzZS4NCg0KSSBkb27igJl0IGtub3cgZW5vdWdoIGFib3V0IFJGQzc1MTUsIGlzIGl0IHBv c3NpYmxlIHRvIGRvIHNvbWV0aGluZyBsaWtlIHJlZ3VsYXIgU0hBMyBvciB3b3VsZCBteSBmaW5n ZXJwcmludCB1c2UgY2FzZSBuZWVkIHRvIGp1c3QgcHVibGljbHkgZGVjbGFyZSB0aGUgc2lnbmF0 dXJlIGtleSB0byB1c2U/DQoNCg0KLS0NClN0aWFuIFNvaWxhbmQtUmV5ZXMsIFRoZSBVbml2ZXJz aXR5IG9mIE1hbmNoZXN0ZXINCmh0dHBzOi8vd3d3LmVzY2llbmNlbGFiLm9yZy51ay8NCmh0dHBz Oi8vb3JjaWQub3JnLzAwMDAtMDAwMS05ODQyLTk3MTgNCiAgICBQbGVhc2Ugbm90ZSB0aGF0IEkg bWF5IHdvcmsgZmxleGlibHkg4oCTIHdoaWxzdCBpdCBzdWl0cyBtZSB0byBlbWFpbCBub3csDQog ICAgSSBkbyBub3QgZXhwZWN0IGEgcmVzcG9uc2Ugb3IgYWN0aW9uIG91dHNpZGUgb2YgeW91ciBv d24gd29ya2luZyBob3Vycy4NCg0KDQpGcm9tOiBhcnQgPGFydC1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgQnJldCBKb3JkYW4gPGpvcmRhbi5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFdl ZG5lc2RheSwgMjggQXByaWwgMjAyMSBhdCAwMzoyOQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFy ZHRAZ21haWwuY29tPg0KQ2M6ICJhcnRAaWV0Zi5vcmciIDxhcnRAaWV0Zi5vcmc+LCBESVNQQVRD SCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+LCAicmZjLWlzZUByZmMtZWRpdG9yLm9yZyIgPHJmYy1pc2VA cmZjLWVkaXRvci5vcmc+LCBJRVRGIFNlY0Rpc3BhdGNoIDxTZWNkaXNwYXRjaEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbYXJ0XSBQbGFpbiB0ZXh0IEpTT04gZGlnaXRhbCBzaWduYXR1cmVzDQoN Ckx1Y2tpbHkgdGhpcyB0aW1lIHdlIGhhdmUgUkZDODc4NSB0aGF0IHNvbHZlcyB0aGUgY2Fub25p Y2FsaXphdGlvbiBwcm9ibGVtIGZvciBKU09OLg0KDQpCcmV0DQpTZW50IGZyb20gbXkgQ29tbW9k b3JlIDY0DQoNClBHUCBGaW5nZXJwcmludDogNjNCNCBGQzUzIDY4MEEgNkI3RCAxNDQ3ICBGMkMw IDc0RjggQUNBRSA3NDE1IDAwNTANCg0KDQoNCk9uIEFwciAyNywgMjAyMSwgYXQgNzozOSBQTSwg RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+IHdyb3RlOg0KSSBhbSBzdXBwb3J0aXZl IG9mIHRoaXMgd29yaywgYW5kIHdvdWxkIGFsc28gYmUgd2lsbGluZyB0byB3b3JrIHRvd2FyZHMg YSBQUy4gSSBhbSBzZWVpbmcgcmFwaWQgZ3Jvd3RoIGluIHRoZSBkZW1hbmQgdG8gZW1iZWQgSldT IGluIEpXUy4NCg0KR2l2ZW4gbXkgZXhwZXJpZW5jZSB3aXRoIFhNTC1EU2lnIChzZWUgYmVsb3cp IG1ha2luZyBpdCBtb3JlIFhNTC1EU2lnIGxpa2UgZG9lcyBub3Qgc291bmQgbGlrZSBhIGdvb2Qg dGhpbmcuDQoNCkZvciBhbnkgaW50ZXJlc3RlZCBpbiBzb21lIEpXVCBoaXN0b3J5LCB3aGVuIHdl IHdlcmUgYnJld2luZyB1cCB3aGF0IGJlY2FtZSBPQXV0aCAyLjAsIHdlIGRpZCBub3Qgd2FudCB0 byB0aWUgYSB0b2tlbiBmb3JtYXQgdG8gdGhlIGltcGxlbWVudGF0aW9uIGFzIG1hbnkgZGVwbG95 bWVudHMgaGFkIHRoZWlyIG93biBwcm9wcmlldGFyeSB0b2tlbiBmb3JtYXRzIC0tIGJ1dCB3ZSBr bmV3IG5ldyBkZXBsb3ltZW50cyB3b3VsZCBiZW5lZml0IGZyb20gc3RhbmRhcmRpemluZyBhIHRv a2VuLg0KDQpPdXIgcmVxdWlyZW1lbnRzIHdlcmU6DQotIFVSTCBzYWZlIChhY2Nlc3MgdG9rZW5z IGF0IHRoZSB0aW1lIHdlcmUgb2Z0ZW4gcGFzc2VkIGFzIGEgcXVlcnkgcGFyYW1ldGVyIC0tIEkg a25vdywgbm90IHRoZSBiZXN0IGlkZWEsIGJ1dCB3b3JraW5nIHdpdGggd2hhdCBwZW9wbGUgd2Fu dGVkKQ0KLSBIVFRQIGhlYWRlciBzYWZlDQotIHJpY2hlciB0aGFuIG5hbWUgLyB2YWx1ZSBwYWly cw0KDQpPcHRpb25zIHdlIGNvbnNpZGVyZWQ6DQpBU04uMSAtIHRoZSA2MHMgYXJlIGNhbGxpbmcg YW5kIHdhbnQgdGhlaXIgZGF0YSBiYWNrDQpYTUwtRFNpZyAtIG5vdCBVUkwgc2FmZSwgbGFyZ2Ug c2l6ZSwgYW5kIEkgcGVyc29uYWxseSBoYWQgbWFueSBzY2FycyBjYW5vbmljYWxpemluZyBYTUwu IChBbiBlYXJsaWVyIGNvbXBhbnkgb2YgbWluZSBoYWQgYSBjb250cmFjdCB0byBidWlsZCBYTUwt RFNpZyBsaWJyYXJpZXMgZm9yIGEgZmV3IGxhbmd1YWdlcykNCg0KSlNPTiB3YXMgYmVjb21pbmcg dmVyeSBjb29sIGF0IHRoYXQgdGltZSwgYW5kIHdpdGggYmFzZSA2NCBVUkwgc2FmZSBlbmNvZGlu ZyB0aGUgc3RyaW5nLCBpdCB3YXMgVVJMIHNhZmUsIGFuZCB0cmVhdGluZyB0aGUgSlNPTiB0ZXh0 IGFzIGJpbmFyeSBkZWFsdCB3aXRoIHRoZSBjYW5vbmljYWxpemF0aW9uIGNvbmNlcm5zIC0tIGFu ZCBKU09OIGNhbm9uaWNhbGl6YXRpb24gZGlkIG5vdCBleGlzdC4NCg0KVXNpbmcgYSBkb3QgYXMg dGhlIHNlcGFyYXRvciBiZXR3ZWVuIGhlYWRlciwgcGF5bG9hZCwgYW5kIHNpZ25hdHVyZSBtYWRl IGl0IGVhc3kgdG8gcGFyc2UuIFRoZSBkb3Qgd2FzIFVSTCBzYWZlLCBidXQgbm90IGluIHRoZSBi YXNlIDY0IHNldC4NCg0KQW5kIFNpbXBsZSBXZWIgVG9rZW5zIHdlcmUgYm9ybiAtLSB0byBiZSBy ZW5hbWVkIEpTT04gV2ViIFRva2Vucy4NCg0KL0RpY2sNCg0KDQoNCg0KW0ltYWdlIHJlbW92ZWQg Ynkgc2VuZGVyLl3hkKcNCg0KT24gVHVlLCBBcHIgMjcsIDIwMjEgYXQgODoyOCBBTSBCcmV0IEpv cmRhbiA8am9yZGFuLmlldGZAZ21haWwuY29tPG1haWx0bzpqb3JkYW4uaWV0ZkBnbWFpbC5jb20+ PiB3cm90ZToNCkRlYXIgRGlzcGF0Y2gsDQoNCkFuZGVycyBSdW5kZ3JlbiwgU2FtdWVsLCBFcmR0 bWFuLCBhbmQgSSBoYXZlIGJlZW4gd29ya2luZyBvbiBhbiBJRCBmb3IgeW91ciBjb25zaWRlcmF0 aW9uLiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdG8gdXNlIEpXUyBhbmQgSkNTIHRvIGNy ZWF0ZSBwbGFpbi10ZXh0IEpTT04gc2lnbmF0dXJlcy4gVGhlIGFic3RyYWN0IHJlYWRzIGFzIGZv bGxvd3M6DQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIGZvciBleHRlbmRpbmcg dGhlIHNjb3BlIG9mIHRoZSBKU09OIFdlYiBTaWduYXR1cmUgKEpXUykgc3RhbmRhcmQsIGNhbGxl ZCBKV1MvQ1QuICBCeSBjb21iaW5pbmcgdGhlIGRldGFjaGVkIG1vZGUgb2YgSldTIHdpdGggdGhl IEpTT04gQ2Fub25pY2FsaXphdGlvbiBTY2hlbWUgKEpDUyksIEpXUy9DVCBlbmFibGVzIEpTT04g b2JqZWN0cyB0byByZW1haW4gaW4gdGhlIEpTT04gZm9ybWF0IGFmdGVyIGJlaW5nIHNpZ25lZCAo YWthICJDbGVhciBUZXh0IiBzaWduaW5nKS4gIEluIGFkZGl0aW9uIHRvIHN1cHBvcnRpbmcgYSBj b25zaXN0ZW50IGRhdGEgZm9ybWF0LCB0aGlzIGFycmFuZ2VtZW50IGFsc28gc2ltcGxpZmllcyBk b2N1bWVudGF0aW9uLCBkZWJ1Z2dpbmcsIGFuZCBsb2dnaW5nLiAgVGhlIGFiaWxpdHkgdG8gZW1i ZWQgc2lnbmVkIEpTT04gb2JqZWN0cyBpbiBvdGhlciBKU09OIG9iamVjdHMsIG1ha2VzIHRoZSB1 c2Ugb2YgY291bnRlci1zaWduYXR1cmVzIHN0cmFpZ2h0Zm9yd2FyZC4NCg0KVGhlIGRhdGEgdHJh Y2tlciBwYWdlIGZvciB0aGlzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1qb3JkYW4tandzLWN0Lw0KDQpBcyB5b3Uga25vdyB0aGVyZSBhcmUgbGFyZ2UgZWNvc3lzdGVt cyB0aGF0IG5lZWRzIGRpZ2l0YWwgc2lnbmF0dXJlcyBmb3IgcGxhaW4gdGV4dCBKU09OIGRhdGEs IG1lYW5pbmcgd2hlcmUgdGhlIEpTT04gZGF0YSBpcyBub3QgYmFzZTY0IGVuY29kZWQuIFRoaXMg SUQgcHJvdmlkZXMgYSBzb2x1dGlvbiB1c2luZyBleGlzdGluZyBJRVRGIFJGQ3MgdG8gbWFrZSB0 aGlzIHdvcmsuIEZ1cnRoZXIsIHRoaXMgd29yayBsb29rcyB0byBiZSBhZG9wdGVkIGJ5IG1hbnkg Z3JvdXBzIGFuZCBvcmdhbml6YXRpb25zIGZyb20gZmluYW5jaWFsIHNlcnZpY2VzLCB0aHJlYXQg aW50ZWxsaWdlbmNlLCBhbmQgaW5jaWRlbnQgcmVzcG9uc2UuDQoNCldlIGFyZSBub3Qgc3VyZSB3 aGF0IGRpcmVjdGlvbiB3b3VsZCBiZSBiZXN0IGZvciB0aGlzIHdvcmsgaW4gdGhlIElFVEYsIHNo b3VsZCB3ZSBzZW5kIHRvIHRoZSBJU0UgZm9yIHB1YmxpY2F0aW9uIG9yIGRvIHlvdSB3YW50IHRv IGNyZWF0ZSBhIHdvcmtpbmcgZ3JvdXAuIFVsdGltYXRlbHkgdGhlcmUgaXMgYSBsb3Qgb2Ygd29y ayB0aGF0IGNvdWxkIGJlIGRvbmUgaW4gdGhpcyBzcGFjZSB0byBtZWV0IHRoZSBuZWVkcyBvZiB0 aGUgbWFya2V0LiBXZSB3b3VsZCBiZSBoYXBweSB3aXRoIHJlbGVhc2luZyB0aGVzZSBJRHMgZm9y IElTRSBwdWJsaWNhdGlvbiwgb3IgZm9yIGNyZWF0aW5nIGEgd29ya2luZyBncm91cCB0byBtb3Zl IHRoZW0gZm9yd2FyZC4gSXQgaXMganVzdCBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZSBtYXJr ZXQgaXMgaW4gZGVzcGVyYXRlIG5lZWQgb2YgdGhlc2Ugc29sdXRpb25zLiBJZiB5b3Ugd2FudCB0 byB0YWtlIGl0IGZvciBhIHNwaW4sIHRoZXJlIGlzIGEgSldTL0NUIHBsYXlncm91bmQgYXQ6IGh0 dHBzOi8vbW9iaWxlcGtpLm9yZy9qd3MtY3QNCg0KVGhhbmtzDQpCcmV0DQoNCi0tDQoNClNlbnQg ZnJvbSBteSBUSS05OS80QQ0KDQoNCg0KUEdQIEZpbmdlcnByaW50OiA2M0I0IEZDNTMgNjgwQSA2 QjdEIDE0NDcgIEYyQzAgNzRGOCBBQ0FFIDc0MTUgMDA1MA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmFydCBtYWlsaW5nIGxpc3QNCmFydEBpZXRmLm9y ZzxtYWlsdG86YXJ0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hcnQNCg== --_000_CA685270A83449AF993A75F0D70308DBmanchesteracuk_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkV1cGhlbWlh IFVDQVMiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDQgMSAyIDIgMSA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Iklvc2V2a2EgVGVybSI7DQoJcGFub3NlLTE6MiAwIDUgOSAzIDAgMCAwIDAg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu cDEsIGxpLnAxLCBkaXYucDENCgl7bXNvLXN0eWxlLW5hbWU6cDE7DQoJbWFyZ2luOjBjbTsNCgli YWNrZ3JvdW5kOndoaXRlOw0KCWZvbnQtc2l6ZTo4LjVwdDsNCglmb250LWZhbWlseToiSW9zZXZr YSBUZXJtIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLmgzDQoJe21zby1zdHlsZS1uYW1lOmgzO30N CnNwYW4uczENCgl7bXNvLXN0eWxlLW5hbWU6czE7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij7igKYgSSB0aGluayBJIGdvdCBpdCB3cm9uZyBiZWxvdywgYXMgdGhlIEpXUyBTaWduYXR1cmUg aWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3QgYWxzbyBuZWVkcyB0byBpbmNsdWRlIHRoZSBKV1Mg aGVhZGVyPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlBlcmhhcHMgdGhpcyBpcyB3aHkgaXQgbmVlZHMgdG8gYmUgY2xhcmlm aWVkIGhlcmUhDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENv bG9yIEVtb2ppJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mIzEyODUyMjs8L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlN0aWFuIFNvaWxhbmQtUmV5ZXMsIFRoZSBVbml2ZXJz aXR5IG9mIE1hbmNoZXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZXNjaWVuY2VsYWIub3JnLnVrLyI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHBzOi8vd3d3LmVzY2llbmNlbGFiLm9yZy51ay88L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVm PSJodHRwczovL29yY2lkLm9yZy8wMDAwLTAwMDEtOTg0Mi05NzE4Ij48c3BhbiBzdHlsZT0iY29s b3I6IzA1NjNDMSI+aHR0cHM6Ly9vcmNpZC5vcmcvMDAwMC0wMDAxLTk4NDItOTcxODwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZu YnNwOyZuYnNwOyBQbGVhc2Ugbm90ZSB0aGF0IEkgbWF5IHdvcmsgZmxleGlibHkg4oCTIHdoaWxz dCBpdCBzdWl0cyBtZSB0byBlbWFpbCBub3csDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SSBkbyBub3QgZXhwZWN0 IGEgcmVzcG9uc2Ugb3IgYWN0aW9uIG91dHNpZGUgb2YgeW91ciBvd24gd29ya2luZyBob3Vycy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmFydCAmbHQ7YXJ0LWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBTdGlhbiBTb2lsYW5kLVJleWVzICZsdDtz b2lsYW5kLXJleWVzQG1hbmNoZXN0ZXIuYWMudWsmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5l c2RheSwgMjggQXByaWwgMjAyMSBhdCAxMDoyMjxicj4NCjxiPlRvOiA8L2I+QnJldCBKb3JkYW4g Jmx0O2pvcmRhbi5pZXRmQGdtYWlsLmNvbSZndDssIERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRA Z21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7YXJ0QGlldGYub3JnJnF1b3Q7ICZs dDthcnRAaWV0Zi5vcmcmZ3Q7LCBJRVRGIFNlY0Rpc3BhdGNoICZsdDtTZWNkaXNwYXRjaEBpZXRm Lm9yZyZndDssIERJU1BBVENIICZsdDtkaXNwYXRjaEBpZXRmLm9yZyZndDssICZxdW90O3JmYy1p c2VAcmZjLWVkaXRvci5vcmcmcXVvdDsgJmx0O3JmYy1pc2VAcmZjLWVkaXRvci5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbYXJ0XSBQbGFpbiB0ZXh0IEpTT04gZGlnaXRhbCBzaWdu YXR1cmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBkcmFmdCBp cyB3ZWxsIHdyaXR0ZW4gYW5kIGFuIGFwcHJvYWNoIHdlIHdvdWxkIGxpa2UgdG8gdXNlIGluIElF RUUgMjc5MSwgYW5kIGZyb20geW91ciB0ZXh0IGl0IHdpbGwgZml0IHJpZ2h0IGludG8gb3VyDQo8 YSBocmVmPSJodHRwczovL29wZW5zb3VyY2UuaWVlZS5vcmcvMjc5MS1vYmplY3QvaWVlZS0yNzkx LXNjaGVtYS8tL2Jsb2IvbWFzdGVyLzI3OTFvYmplY3QuanNvbiNMMTI5Ij4NCuKAnGV0YWfigJ0g ZmllbGQ8L2E+IHdoZXJlIHdlIGhvcGUgZm9yIGEgY29uc2lzdGVudCBoYXNoaW5nIG1lY2hhbmlz bSB0byBkZXRlY3QgY2hhbmdlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGRyYWZ0IHNlZW1zIHRvIGJ1aWxkIG9uIEpT T04gV2ViIFNpZ25hdHVyZSAoPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZj L3JmYzc1MTcuaHRtbCI+UkZDNzUxNTwvYT4pIGFuZCBKU09OIFdlYiBLZXkgKDwvc3Bhbj48YSBo cmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNzUxNy5odG1sIj5SRkM3NTE3 PC9hPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+KSwNCiBidXQgdGhl IDMuMS4zIGlzIGEgYml0IHRvbyBicmllZiBmb3IgcmVhZGVycyBuZXcgdG8gdGhlc2Ugc3RhbmRh cmRzLCBwZXJoYXBzIGdpdmUgYSBicmllZiBzdW1tYXJ5IGZvciB0aGlzIGV4YW1wbGUsIGVzcGVj aWFsbHkgYXMgUkZDNzUxNyBpcyBxdWl0ZSBjb21wcmVoZW5zaXZlIHdpdGggbWFueSBvcHRpb25z Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5JbiBwYXJ0aWN1bGFyIGl0IGlzIHVuY2xlYXIgaWYgdGhlIEpXUyBIZWFkZXIgYWxz byBuZWVkcyB0byBiZSBKU09OIGNhbm9uaWNhbGl6ZWQg4oCTIHdoaWNoIG1heSBiZSBhIGdvb2Qg aWRlYSBmb3IgY29uc2lzdGVudCDigJxoYXNo4oCdIHB1cnBvc2VzIGxpa2UgaW4gb3VyIHVzZSBj YXNlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5IZXJl4oCZcyBteSByb3VnaCBzdWdnZXN0aW9uIOKAkyBwcm9iYWJseSB3cm9u ZyEgTXkgYWRkaXRpb25zIHVuaW5kZW50ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjMuMS4zLiZuYnNwOyBHZW5lcmF0ZSBh IEpXUyBTdHJpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgVXNlIHRoZSByZXN1bHQgb2YgdGhlIHByZXZpb3VzIHN0ZXAg YXMgJnF1b3Q7SldTIFBheWxvYWQmcXVvdDsgdG8gdGhlIHNpZ25hdHVyZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwcm9jZXNzIGRlc2NyaWJlZCBpbiBBcHBlbmRpeCBGIG9m IEpXUyBbUkZDNzUxNV0uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+SW4gc2hvcnQgYSBkZXRhY2hlZCBKV1MgaXMgcmVwcmVzZW50ZWQgYXMgdGhl IHN0cmluZyBjb25jYXRlbmF0ZWQgZnJvbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCQVNF NjRVUkwoVVRGOChKV1MgUHJvdGVjdGVkIEhlYWRlcikpIHx8ICcuJyB8fDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8fCAnLicgfHw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQkFTRTY0VVJM KEpXUyBTaWduYXR1cmUpPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+Tm90aWNlLCBmb3IgY29tcGFyaXNvbiB3aXRoIHRoZSA8c3BhbiBjbGFzcz0i aDMiPkpXUyBDb21wYWN0IFNlcmlhbGl6YXRpb24sIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBjbGFzcz0iaDMiPnRoYXQgdGhlIEpXUyBQYXlsb2FkIGlzIG5vdCBpbmNsdWRl ZCBpbiB0aGUgZGV0YWNoZWQgSldTIFN0cmluZywgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIGNsYXNzPSJoMyI+YnV0IHJlcGxhY2VkIGJ5IGFuIGVtcHR5IHN0cmluZy48L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IEZvciB0aGUgZXhhbXBsZSwgdGhlIEpXUyBoZWFkZXIgaXMgYXNzdW1lZCB0 byBiZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgeyZxdW90O2FsZyZxdW90OzomcXVvdDtIUzI1NiZxdW90O308bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgYWJvdmUg ZXhhbXBsZSBpcyBlcXVhbCB0byBpdHMgb3duIEpDUyBjYW5vbmljYWxpemF0aW9uLiA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5KU09OIENhbm9uaWNhbGl6YXRpb24gaXMgbm90IGEgcmVxdWlyZW1l bnQgZm9yIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5KV1MgSGVhZGVyLCBob3dldmVyIHRo aXMgaXMgUkVDT01NRU5ERUQsIGNvbWJpbmVkIHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5h IGZpeGVkIGFsZ29yaXRobSBjaG9pY2UsIGlmIGdlbmVyYXRpbmcgYSBjb25zaXN0ZW50IEpXUy9D VCBzaWduYXR1cmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGF0IGlzIHMgYWxzbyB0byBiZSB1 c2VkIGFzIGFzIGEgY2Fub25pY2FsIHZlcnNpb24gaWRlbnRpZmllciA8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5vZiB0aGUgSlNPTiBwYXlsb2FkIGNvbnRlbnQsIGUuZy4gYXMgYSBzdHJvbmcgRVRh ZyAoUkZDNzIzMikuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+VGhlIEpXUyBTaWduYXR1cmUgb2YgdGhlIGNhbm9uaWNhbGl6ZWQgSlNPTiBwYXls b2FkLCB1c2luZyB0aGUga2V5IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNwZWNpZmllZCBpbiBT ZWN0aW9uIDMsIGlzIHRoZSBieXRlczxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0icDEiPjxz cGFuIGNsYXNzPSJzMSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAx Ij48c3BhbiBjbGFzcz0iczEiPjU0IDc1IDQ4IGI0IDIwIDQyIDZmIGM0IDM5IHg4IDhlIDNkIDhh IDY2IGFiIHhlIDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBj bGFzcz0iczEiPmQyIDVlIDRiIDExIGY2IGI4IGI1IDM0IHhlIDFhIDkwIDNmIDk2IDYzIGMzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5FbmNvZGluZyBhcyBCYXNlNjQ8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgcmVzdWx0aW5n IGNvbmNhdGVuYXRlZCBKV1Mgc3RyaW5nIHNob3VsZCB0aGVuIHJlYWQgYXMgZm9sbG93czo8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgZXlKaGJHY2lPaUpJVXpJMU5pSjkuLlZIVkl0Q0JDYjhRNUNJLTQ5aW1hckR0SmVTeEgy dUxVMERocVFQNVpqdzQ8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+WW91IG1h eSB3YW50IHRvIG1vdmUgbXkgRVRhZyByZWNvbW1lbmRhdGlvbiB0byBhbiBhcHBlbmRpeCwgYXMg SSBkb27igJl0IGZlZWwgaXQgZml0cyB3ZWxsIHdoZXJlIEkgcHV0IGl0LCBidXQgSSB0aGluayBp dCBpcyB3b3J0aCBwb2ludGluZyBvdXQuIEFzIGEgdXNlIGNhc2UuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgZG9u4oCZdCBr bm93IGVub3VnaCBhYm91dCBSRkM3NTE1LCBpcyBpdCBwb3NzaWJsZSB0byBkbyBzb21ldGhpbmcg bGlrZSByZWd1bGFyIFNIQTMgb3Igd291bGQgbXkgZmluZ2VycHJpbnQgdXNlIGNhc2UgbmVlZCB0 byBqdXN0IHB1YmxpY2x5IGRlY2xhcmUgdGhlIHNpZ25hdHVyZSBrZXkgdG8gdXNlPw0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U3RpYW4gU29pbGFuZC1SZXllcywg VGhlIFVuaXZlcnNpdHkgb2YgTWFuY2hlc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5lc2NpZW5jZWxhYi5vcmcudWsv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly93d3cuZXNjaWVuY2VsYWIub3Jn LnVrLzwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxhIGhyZWY9Imh0dHBzOi8vb3JjaWQub3JnLzAwMDAtMDAwMS05ODQyLTk3MTgiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL29yY2lkLm9yZy8wMDAwLTAwMDEtOTg0Mi05 NzE4PC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBsZWFzZSBub3RlIHRoYXQgSSBtYXkgd29yayBmbGV4aWJs eSDigJMgd2hpbHN0IGl0IHN1aXRzIG1lIHRvIGVtYWlsIG5vdywNCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJIGRv IG5vdCBleHBlY3QgYSByZXNwb25zZSBvciBhY3Rpb24gb3V0c2lkZSBvZiB5b3VyIG93biB3b3Jr aW5nIGhvdXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+YXJ0 ICZsdDthcnQtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEJyZXQgSm9yZGFuICZs dDtqb3JkYW4uaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwg MjggQXByaWwgMjAyMSBhdCAwMzoyOTxicj4NCjxiPlRvOiA8L2I+RGljayBIYXJkdCAmbHQ7ZGlj ay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDthcnRAaWV0Zi5vcmcm cXVvdDsgJmx0O2FydEBpZXRmLm9yZyZndDssIERJU1BBVENIICZsdDtkaXNwYXRjaEBpZXRmLm9y ZyZndDssICZxdW90O3JmYy1pc2VAcmZjLWVkaXRvci5vcmcmcXVvdDsgJmx0O3JmYy1pc2VAcmZj LWVkaXRvci5vcmcmZ3Q7LCBJRVRGIFNlY0Rpc3BhdGNoICZsdDtTZWNkaXNwYXRjaEBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFthcnRdIFBsYWluIHRleHQgSlNPTiBkaWdp dGFsIHNpZ25hdHVyZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5MdWNraWx5IHRoaXMgdGlt ZSB3ZSBoYXZlIFJGQzg3ODUgdGhhdCBzb2x2ZXMgdGhlIGNhbm9uaWNhbGl6YXRpb24gcHJvYmxl bSBmb3IgSlNPTi4mbmJzcDs8YnI+DQo8YnI+DQpCcmV0Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIG15IENvbW1vZG9yZSA2NDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UEdQIEZpbmdlcnByaW50 OiZuYnNwOzYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAmbmJzcDtGMkMwIDc0RjggQUNBRSA3NDE1 IDAwNTA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gQXByIDI3LCAyMDIxLCBh dCA3OjM5IFBNLCBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHN1cHBvcnRpdmUgb2YgdGhpcyB3b3JrLCBhbmQgd291 bGQgYWxzbyBiZSB3aWxsaW5nIHRvIHdvcmsgdG93YXJkcyBhIFBTLiBJIGFtIHNlZWluZyByYXBp ZCBncm93dGggaW4gdGhlIGRlbWFuZCB0byBlbWJlZCBKV1MgaW4gSldTLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2l2ZW4gbXkgZXhwZXJpZW5jZSB3aXRo IFhNTC1EU2lnIChzZWUgYmVsb3cpIG1ha2luZyBpdCBtb3JlIFhNTC1EU2lnIGxpa2UgZG9lcyBu b3Qgc291bmQgbGlrZSBhIGdvb2QgdGhpbmcuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Rm9yIGFueSBpbnRlcmVzdGVkJm5ic3A7aW4gc29tZSBKV1QgaGlzdG9yeSwgd2hl biB3ZSB3ZXJlIGJyZXdpbmcgdXAgd2hhdCBiZWNhbWUgT0F1dGggMi4wLCB3ZSBkaWQgbm90IHdh bnQgdG8gdGllIGEgdG9rZW4gZm9ybWF0IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBhcyBtYW55IGRl cGxveW1lbnRzIGhhZCB0aGVpciBvd24gcHJvcHJpZXRhcnkgdG9rZW4gZm9ybWF0cyAtLSBidXQg d2Uga25ldyBuZXcgZGVwbG95bWVudHMNCiB3b3VsZCBiZW5lZml0Jm5ic3A7ZnJvbSBzdGFuZGFy ZGl6aW5nIGEgdG9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk91ciByZXF1aXJlbWVudHMgd2VyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVVJMIHNhZmUgKGFjY2VzcyB0b2tlbnMg YXQgdGhlIHRpbWUgd2VyZSBvZnRlbiBwYXNzZWQgYXMgYSBxdWVyeSBwYXJhbWV0ZXImbmJzcDst LSBJIGtub3csIG5vdCB0aGUgYmVzdCBpZGVhLCBidXQgd29ya2luZyZuYnNwO3dpdGggd2hhdCBw ZW9wbGUgd2FudGVkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LSBIVFRQIGhlYWRlciBzYWZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHJpY2hlciB0aGFuIG5hbWUgLyB2YWx1ZSBwYWlyczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PcHRp b25zIHdlIGNvbnNpZGVyZWQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BU04uMSAtIHRoZSA2MHMgYXJlIGNhbGxpbmcgYW5kIHdhbnQgdGhlaXIg ZGF0YSBiYWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5YTUwtRFNpZyAtIG5vdCBVUkwgc2FmZSwgbGFyZ2Ugc2l6ZSwgYW5kIEkgcGVyc29uYWxs eSBoYWQgbWFueSBzY2FycyBjYW5vbmljYWxpemluZyBYTUwuIChBbiBlYXJsaWVyIGNvbXBhbnkg b2YgbWluZSBoYWQgYSBjb250cmFjdCB0byBidWlsZCBYTUwtRFNpZyBsaWJyYXJpZXMgZm9yIGEg ZmV3IGxhbmd1YWdlcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SlNPTiB3YXMgYmVjb21pbmcgdmVyeSBjb29sIGF0IHRoYXQgdGltZSwgYW5k IHdpdGggYmFzZSA2NCBVUkwgc2FmZSBlbmNvZGluZyB0aGUgc3RyaW5nLCBpdCB3YXMgVVJMIHNh ZmUsIGFuZCB0cmVhdGluZyB0aGUgSlNPTiB0ZXh0IGFzIGJpbmFyeSBkZWFsdCB3aXRoIHRoZSBj YW5vbmljYWxpemF0aW9uIGNvbmNlcm5zIC0tIGFuZCBKU09OIGNhbm9uaWNhbGl6YXRpb24gZGlk IG5vdCBleGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VXNpbmcgYSBkb3QgYXMgdGhlIHNlcGFyYXRvciZuYnNwO2JldHdlZW4gaGVhZGVy LCBwYXlsb2FkLCBhbmQgc2lnbmF0dXJlIG1hZGUgaXQgZWFzeSB0byBwYXJzZS4gVGhlIGRvdCB3 YXMgVVJMIHNhZmUsIGJ1dCBub3QgaW4gdGhlIGJhc2UgNjQgc2V0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgU2ltcGxlIFdlYiBUb2tl bnMgd2VyZSBib3JuIC0tIHRvIGJlIHJlbmFtZWQgSlNPTiBXZWIgVG9rZW5zLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowY20iPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMzIiIGhlaWdodD0iMzIi IHN0eWxlPSJ3aWR0aDouMzMzM2luO2hlaWdodDouMzMzM2luIiBpZD0iX3gwMDAwX2kxMDI1IiBz cmM9ImNpZDp+V1JEMDAwMC5qcGciIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtFdXBoZW1p YSBVQ0FTJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDI3LCAyMDIx IGF0IDg6MjggQU0gQnJldCBKb3JkYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpqb3JkYW4uaWV0ZkBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qb3JkYW4uaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBE aXNwYXRjaCw8YnI+DQo8YnI+DQpBbmRlcnMgUnVuZGdyZW4sIFNhbXVlbCwgRXJkdG1hbiwgYW5k IEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gYW4gSUQgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4gVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIHVzZSBKV1MgYW5kIEpDUyB0byBjcmVhdGUgcGxh aW4tdGV4dCBKU09OIHNpZ25hdHVyZXMuIFRoZSBhYnN0cmFjdCByZWFkcyBhcyBmb2xsb3dzOjxi cj4NCjxicj4NClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIGZvciBleHRlbmRpbmcg dGhlIHNjb3BlIG9mIHRoZSBKU09OIFdlYiBTaWduYXR1cmUgKEpXUykgc3RhbmRhcmQsIGNhbGxl ZCBKV1MvQ1QuJm5ic3A7IEJ5IGNvbWJpbmluZyB0aGUgZGV0YWNoZWQgbW9kZSBvZiBKV1Mgd2l0 aCB0aGUgSlNPTiBDYW5vbmljYWxpemF0aW9uIFNjaGVtZSAoSkNTKSwgSldTL0NUIGVuYWJsZXMg SlNPTiBvYmplY3RzIHRvIHJlbWFpbiBpbiB0aGUgSlNPTiBmb3JtYXQgYWZ0ZXINCiBiZWluZyBz aWduZWQgKGFrYSAmcXVvdDtDbGVhciBUZXh0JnF1b3Q7IHNpZ25pbmcpLiZuYnNwOyBJbiBhZGRp dGlvbiB0byBzdXBwb3J0aW5nIGEgY29uc2lzdGVudCBkYXRhIGZvcm1hdCwgdGhpcyBhcnJhbmdl bWVudCBhbHNvIHNpbXBsaWZpZXMgZG9jdW1lbnRhdGlvbiwgZGVidWdnaW5nLCBhbmQgbG9nZ2lu Zy4mbmJzcDsgVGhlIGFiaWxpdHkgdG8gZW1iZWQgc2lnbmVkIEpTT04gb2JqZWN0cyBpbiBvdGhl ciBKU09OIG9iamVjdHMsIG1ha2VzIHRoZSB1c2Ugb2YgY291bnRlci1zaWduYXR1cmVzDQogc3Ry YWlnaHRmb3J3YXJkLjxicj4NCjxicj4NClRoZSBkYXRhIHRyYWNrZXIgcGFnZSBmb3IgdGhpczog PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9yZGFuLWp3 cy1jdC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWpvcmRhbi1qd3MtY3QvPC9hPjxicj4NCjxicj4NCkFzIHlvdSBrbm93IHRoZXJlIGFy ZSBsYXJnZSBlY29zeXN0ZW1zIHRoYXQgbmVlZHMgZGlnaXRhbCBzaWduYXR1cmVzIGZvciBwbGFp biB0ZXh0IEpTT04gZGF0YSwgbWVhbmluZyB3aGVyZSB0aGUgSlNPTiBkYXRhIGlzIG5vdCBiYXNl NjQgZW5jb2RlZC4gVGhpcyBJRCBwcm92aWRlcyBhIHNvbHV0aW9uIHVzaW5nIGV4aXN0aW5nIElF VEYgUkZDcyB0byBtYWtlIHRoaXMgd29yay4gRnVydGhlciwgdGhpcyB3b3JrIGxvb2tzIHRvIGJl IGFkb3B0ZWQNCiBieSBtYW55IGdyb3VwcyBhbmQgb3JnYW5pemF0aW9ucyBmcm9tIGZpbmFuY2lh bCBzZXJ2aWNlcywgdGhyZWF0IGludGVsbGlnZW5jZSwgYW5kIGluY2lkZW50IHJlc3BvbnNlLg0K PGJyPg0KPGJyPg0KV2UgYXJlIG5vdCBzdXJlIHdoYXQgZGlyZWN0aW9uIHdvdWxkIGJlIGJlc3Qg Zm9yIHRoaXMgd29yayBpbiB0aGUgSUVURiwgc2hvdWxkIHdlIHNlbmQgdG8gdGhlIElTRSBmb3Ig cHVibGljYXRpb24gb3IgZG8geW91IHdhbnQgdG8gY3JlYXRlIGEgd29ya2luZyBncm91cC4gVWx0 aW1hdGVseSB0aGVyZSBpcyBhIGxvdCBvZiB3b3JrIHRoYXQgY291bGQgYmUgZG9uZSBpbiB0aGlz IHNwYWNlIHRvIG1lZXQgdGhlIG5lZWRzIG9mIHRoZSBtYXJrZXQuIFdlDQogd291bGQgYmUgaGFw cHkgd2l0aCByZWxlYXNpbmcgdGhlc2UgSURzIGZvciBJU0UgcHVibGljYXRpb24sIG9yIGZvciBj cmVhdGluZyBhIHdvcmtpbmcgZ3JvdXAgdG8gbW92ZSB0aGVtIGZvcndhcmQuIEl0IGlzIGp1c3Qg aW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0aGUgbWFya2V0IGlzIGluIGRlc3BlcmF0ZSBuZWVkIG9m IHRoZXNlIHNvbHV0aW9ucy4gSWYgeW91IHdhbnQgdG8gdGFrZSBpdCBmb3IgYSBzcGluLCB0aGVy ZSBpcyBhIEpXUy9DVCBwbGF5Z3JvdW5kDQogYXQ6IDxhIGhyZWY9Imh0dHBzOi8vbW9iaWxlcGtp Lm9yZy9qd3MtY3QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21vYmlsZXBraS5vcmcvandzLWN0 PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmV0 PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0Ij5TZW50IGZyb20gbXkgVEktOTkvNEE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+UEdQIEZpbmdlcnByaW50OiZuYnNwOzYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAmbmJz cDtGMkMwIDc0RjggQUNBRSZuYnNwOzc0MTUgMDA1MDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KYXJ0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzphcnRAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5hcnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FydDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_CA685270A83449AF993A75F0D70308DBmanchesteracuk_-- From nobody Wed Apr 28 08:26:07 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC6A3A1039; Wed, 28 Apr 2021 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOUogliFKVKy; Wed, 28 Apr 2021 08:25:54 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 D749B3A1038; Wed, 28 Apr 2021 08:25:53 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id a11so2141209plh.3; Wed, 28 Apr 2021 08:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AVHEfjnyShwhifQC19SJL37TN7cqfpKhSN8OC+9S0c0=; b=g3smjzvzpFt4TeZx6km/AaWTl9r4XP7+54x7aAO2n6yuXRrsiX5OuQctji87JXWbx2 r3lrd5ghAUMmV89Rfyk3bEiKo/hyoB+rLF2FtZV2UepmFL556DRD1Ra+7s3W0a+Iu6Wi qtylrI6MLju4xdUuWesGERGj4zlmClxZc+cfWH8Xqe2pn/5IxyBpeXDLm7lpuRL2AgU+ 0Qhj8aUnptRyRjW6JC/JtG0W6HTwMqna7LpY/WpOK/Lhj9qNlcfzm9TbIrTNbhgluofs d7RBWfGGtRkR4s0/VknA7Tw4j4rFqfVNmZIB/RvwtwulwcT09cwjaQsZ8RtFL80HahcS CiZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AVHEfjnyShwhifQC19SJL37TN7cqfpKhSN8OC+9S0c0=; b=j7lI8RumG6mMREC3zergZxjBIVjdLlktzqAHeYx4zhXO7GeKaGbiKtG6lSByxN1dNa qhg9gUaeVv5C5ixCwEdaxq0tJd7M5/ZMXA5KHcrR/1FmzzKtQSEP6vcV9I0z73Q7r8HS HnPDWWukBZ05+rTDymNoMWzdbCHjgfJwpCOn/M2EYsU6a+yRKCUuPW3u//W2UQsOCnH7 xIo/kkI/IJk60fHA2GbNG30OzEiP/uWTsssINYgtaaSGyRniwWyIdx99VLKkxLLTot9N ulLg5gk9ryARkCnq0ZvlA6SpJOgGJszzitu7tS0RXS6NtmF23N6FxA8aWDZqY9xfKgDW QCYg== X-Gm-Message-State: AOAM532OqtQoVbyl5NvAtcET6Jp0fa4NEzi5TqOq+xlUmMFZbFbTJJvy EAQvVOy893Juj1o3tYns7W8= X-Google-Smtp-Source: ABdhPJxceEm7FwyHlLcx1sQh8EMqmy2ZXfExzWRmSxyuo2MBYIdSH56HrQYLJwR0B3gkn/lC+QoABg== X-Received: by 2002:a17:90a:b78d:: with SMTP id m13mr4756774pjr.47.1619623550750; Wed, 28 Apr 2021 08:25:50 -0700 (PDT) Received: from smtpclient.apple ([136.36.112.224]) by smtp.gmail.com with ESMTPSA id s21sm5220071pjr.52.2021.04.28.08.25.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Apr 2021 08:25:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Bret Jordan In-Reply-To: <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> Date: Wed, 28 Apr 2021 09:25:46 -0600 Cc: Anders Rundgren , art@ietf.org, DISPATCH , rfc-ise@rfc-editor.org, IETF SecDispatch Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> To: Stefan Santesson X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [dispatch] [Secdispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 15:25:59 -0000 Hi Stefan, Here is one of many use cases. Imagine a connected graph of threat = intelligence data that is all represented in JSON. This data is = processed, searched, analyzed, and forwarded between N number of = entities. Some of the nodes in this connected graph are very large, 100 = of MB to GB. Now entities 1=E2=80=A6N desire to sign both the nodes and = the edge of this graph and issue them out to the ecosystem to increase = trust and verification of the data in the graph. Entities need to be = able create and issue detached signatures for data in the graph that = they do not own but that they know is correct and valid. Further, a = consumer of the data may need to process the signatures independently of = the data in the graph.=20 This is but one of many use cases where traditional JWS
.. does not work.=20 Bret =20 > On Apr 28, 2021, at 3:29 AM, Stefan Santesson = wrote: >=20 > RFC 7797 is supported by common open source such as Nimbus and I use = it > for instances where you obviously do not need a URL safe token. >=20 > As such it works for JWS but Not for JWT. But It works really well and > saves space when URL safeness is not needed. >=20 > So I guess your answer is that it still encapsulates the signed JSON = in > the signature, and that the proposal really is about embedding = signature > in the JSON object being signed (and not about whether the JSON is in > plaintext). >=20 > Could you elaborate why you think it is important to NOT embed signed > data in the signature? >=20 > What is the usecase? >=20 > /Stefan >=20 >=20 > On 2021-04-28 11:00, Anders Rundgren wrote: >> On 2021-04-28 8:52, Stefan Santesson wrote: >>> How is this different/better than implementing RFC 7797 and apply = the >>> header b64=3Dfalse in order to carry plaintext JSON in the payload? >>=20 >> Good question! >>=20 >> Apart from the fact that the data becomes embedded in the JWS >> signature container (=3Dchanging the structure), you cannot really = put >> JSON there: >> https://tools.ietf.org/html/rfc7797#section-5.2 >>=20 >> My guess that the only real-world use of this option is to save an >> internal-only (but technically redundant) Base64Url-operation for >> truly detached data, be it it JSON, PNG, etc. >>=20 >> JWS/CT was designed for signing JSON Objects ({}), and let them = remain >> as such. >>=20 >> Thanx, >> Anders >>=20 >>>=20 >>> /Stefan >>>=20 >>>=20 >>> On 2021-04-28 04:29, Bret Jordan wrote: >>>> Luckily this time we have RFC8785 that solves the canonicalization >>>> problem for JSON. >>>>=20 >>>> Bret >>>>=20 >>>> Sent from my Commodore 64 >>>>=20 >>>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >>>>=20 >>>>> On Apr 27, 2021, at 7:39 PM, Dick Hardt = wrote: >>>>>=20 >>>>> =EF=BB=BF >>>>> I am supportive of this work, and would also be willing to work >>>>> towards a PS. I am seeing rapid growth in the demand to embed JWS >>>>> in JWS. >>>>>=20 >>>>> Given my experience with XML-DSig (see below) making it more >>>>> XML-DSig like does not sound like a good thing. >>>>>=20 >>>>> For any interested in some JWT history, when we were brewing up >>>>> what became OAuth 2.0, we did not want to tie a token format to = the >>>>> implementation as many deployments had their own proprietary token >>>>> formats -- but we knew new deployments would benefit from >>>>> standardizing a token. >>>>>=20 >>>>> Our requirements were: >>>>> - URL safe (access tokens at the time were often passed as a query >>>>> parameter -- I know, not the best idea, but working with what >>>>> people wanted) >>>>> - HTTP header safe >>>>> - richer than name / value pairs >>>>>=20 >>>>> Options we considered: >>>>> ASN.1 - the 60s are calling and want their data back >>>>> XML-DSig - not URL safe, large size, and I personally had many >>>>> scars canonicalizing XML. (An earlier company of mine had a >>>>> contract to build XML-DSig libraries for a few languages) >>>>> JSON was becoming very cool at that time, and with base 64 URL = safe >>>>> encoding the string, it was URL safe, and treating the JSON text = as >>>>> binary dealt with the canonicalization concerns -- and JSON >>>>> canonicalization did not exist. >>>>>=20 >>>>> Using a dot as the separator between header, payload, and >>>>> signature made it easy to parse. The dot was URL safe, but not in >>>>> the base 64 set. >>>>>=20 >>>>> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >>>>>=20 >>>>> /Dick >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =E1=90=A7 >>>>>=20 >>>>> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan = >>>>> wrote: >>>>>=20 >>>>> Dear Dispatch, >>>>>=20 >>>>> Anders Rundgren, Samuel, Erdtman, and I have been working on >>>>> an ID for your consideration. This document describes how to use >>>>> JWS and JCS to create plain-text JSON signatures. The abstract >>>>> reads as follows: >>>>>=20 >>>>> This document describes a method for extending the scope of >>>>> the JSON Web Signature (JWS) standard, called JWS/CT. By >>>>> combining the detached mode of JWS with the JSON Canonicalization >>>>> Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON >>>>> format after being signed (aka "Clear Text" signing). In addition >>>>> to supporting a consistent data format, this arrangement also >>>>> simplifies documentation, debugging, and logging. The ability to >>>>> embed signed JSON objects in other JSON objects, makes the use of >>>>> counter-signatures straightforward. >>>>>=20 >>>>> The data tracker page for this: >>>>> https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ >>>>>=20 >>>>> As you know there are large ecosystems that needs digital >>>>> signatures for plain text JSON data, meaning where the JSON data = is >>>>> not base64 encoded. This ID provides a solution using existing = IETF >>>>> RFCs to make this work. Further, this work looks to be adopted by >>>>> many groups and organizations from financial services, threat >>>>> intelligence, and incident response. >>>>>=20 >>>>> We are not sure what direction would be best for this work >>>>> in the IETF, should we send to the ISE for publication or do you >>>>> want to create a working group. Ultimately there is a lot of work >>>>> that could be done in this space to meet the needs of the market. >>>>> We would be happy with releasing these IDs for ISE publication, or >>>>> for creating a working group to move them forward. It is just >>>>> important to note that the market is in desperate need of these >>>>> solutions. If you want to take it for a spin, there is a JWS/CT >>>>> playground at: https://mobilepki.org/jws-ct >>>>>=20 >>>>> Thanks >>>>> Bret >>>>>=20 >>>>> -- >>>>> Sent from my TI-99/4A >>>>>=20 >>>>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 >>>>> ACAE 7415 0050 >>>>> _______________________________________________ >>>>> art mailing list >>>>> art@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/art >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Secdispatch mailing list >>>> Secdispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>=20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Apr 28 08:55:19 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BF13A11CD; Wed, 28 Apr 2021 08:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 cY3R4VIJPLw2; Wed, 28 Apr 2021 08:55:09 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E563A1248; Wed, 28 Apr 2021 08:55:03 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FVjrN6Q8Bzyft; Wed, 28 Apr 2021 17:55:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 28 Apr 2021 17:55:00 +0200 X-Mao-Original-Outgoing-Id: 641318100.441141-a8485cd991b2d7abdf0fa7b7c59963eb Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> To: art@ietf.org, IETF SecDispatch , DISPATCH , rfc-ise@rfc-editor.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dispatch] [art] [Secdispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 15:55:12 -0000 Signing data at rest certainly is a use case that is worth addressing. =E2=80=9CRepresented in JSON=E2=80=9D is a weird way to say that the = data model that describes those data at rest is somehow compatible with = the JSON data model (which isn=E2=80=99t really fully defined, but that = is a problem that may not hurt you). So if you have a deterministic way = to transform your data at rest into the JSON-like data model subset = supported by RFC8785 (which is in turn based on the RFC7493 I-JSON = subset), you then can use RFC8785 to generate a text string that (using = UTF-8=E2=80=99s deterministic encoding) can in turn be used as a signing = input for well-known signature schemes such as JOSE or COSE. This is pretty much what XMLDSig set out to do, except that the XML data = model is even less well-defined and generating a deterministic signing = input from that is even more interesting. Small matters of = interoperability :-) None of this has anything to do with =E2=80=9Cclear text=E2=80=9D or = =E2=80=9Cplain text", which is an exceedingly bad label to apply to = signing data at rest that are believed to be convertable to an = RFC8785-subset JSON text. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 28 10:06:55 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F333A170C; Wed, 28 Apr 2021 10:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_FI4Fxw18TU; Wed, 28 Apr 2021 10:06:41 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 717AE3A1708; Wed, 28 Apr 2021 10:06:41 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id k3-20020a17090ad083b0290155b934a295so3012922pju.2; Wed, 28 Apr 2021 10:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+xc7t7DZbJLX7ukgaJA/u4nxDO32xC1A8B/8LuZWzZw=; b=sPBoFDGCh7/rMuguZhe6u87kG7MKpOR7jAdfIo/tCmIuRH0z1CFSmJGapxe+S+D6oz fUg4IvM3TNGQo3WqVJFmxpPM3r3/r8K5tC7x3rLIYiHnyhKcnaWyyArTrTlHJFuWrmat W4K1y7FCe199fMLZ4zqxnSU8aCz3jTP+YZVQku/82zWb7ygpuiok2okLaGFbbPTykNep bAmk3NQV35SC4si/ds6LBfj0Ek//CUvroLeg7Qg8CxPuv9irccPJy3io3IFV0baENHaz mCwbz0jrlquHMYDbNhy1ET+FWW7IEs0GVJgI30uvfpFfm1mqSarKdnuHFcbzN+F6qgyS OVXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+xc7t7DZbJLX7ukgaJA/u4nxDO32xC1A8B/8LuZWzZw=; b=Rq+IoLVdm/TVHAbHU0a4Ofo0Nr1m+iuPnlG7APMNrbqL8dGv+n3KYuyghYo/jgsYTv AUWF6GeL3P6/sCEm58oU41xxc0VX0hzo2bdygZv96nvYgjKidst+O0wzBPw9a8vL/ROe h5MOh7LvKYDgtfyPbykThwi6dMt3RpzOcnNPKx3C4lsJNIQ5TBcAKYDtYf0IoMTiDG9m BUou0Rg8Ff7BI9+sBXo2lnZ56P2Qjq5Wut7CWH0+VwqbpWB42OWoBy2qOaP0Y3il5dm+ fBnsBv/C+gnYjyTjiD8s2teqHOpSqMYKbVHJc5PFieN4GvGO+zbgWmVluuEDiT0q1VGO Xx0A== X-Gm-Message-State: AOAM532cYW7E3hPd3tb4R/9fSwAjw9lappqI3ONtkvJPx+LbSi3aeELq 1ubmIGacm8DDsT4+4cM80XA= X-Google-Smtp-Source: ABdhPJzRs2S+frw3ms28zSoGO0Sb8mrBYIX92LpFfW0E0Sfx0L4OUIyxuEc9lzZAB54GtaxNX2RqLQ== X-Received: by 2002:a17:902:9685:b029:e9:abc1:7226 with SMTP id n5-20020a1709029685b02900e9abc17226mr31483518plp.64.1619629599782; Wed, 28 Apr 2021 10:06:39 -0700 (PDT) Received: from smtpclient.apple ([136.36.112.224]) by smtp.gmail.com with ESMTPSA id i126sm260693pfc.20.2021.04.28.10.06.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Apr 2021 10:06:39 -0700 (PDT) From: Bret Jordan Message-Id: <19A94F0B-19B6-4E19-B913-F27C5CB6AD32@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C2F3C8C4-DEFB-4D6B-A423-EA8BE3563CA4" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 28 Apr 2021 11:06:37 -0600 In-Reply-To: Cc: Dick Hardt , "art@ietf.org" , DISPATCH , "rfc-ise@rfc-editor.org" , IETF SecDispatch To: Stian Soiland-Reyes References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [dispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 17:06:47 -0000 --Apple-Mail=_C2F3C8C4-DEFB-4D6B-A423-EA8BE3563CA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Stian. It would be great to use this in IEEE 2791. Let's see what = we need to do to make it more clear.=20 Bret > On Apr 28, 2021, at 3:21 AM, Stian Soiland-Reyes = wrote: >=20 > This draft is well written and an approach we would like to use in = IEEE 2791, and from your text it will fit right into our =E2=80=9Cetag=E2=80= =9D field = where we hope for a consistent hashing mechanism to = detect changes. > =20 > The draft seems to build on JSON Web Signature (RFC7515 = ) and JSON Web Key (RFC7517 = ), but the 3.1.3 is a bit = too brief for readers new to these standards, perhaps give a brief = summary for this example, especially as RFC7517 is quite comprehensive = with many options? > =20 > In particular it is unclear if the JWS Header also needs to be JSON = canonicalized =E2=80=93 which may be a good idea for consistent = =E2=80=9Chash=E2=80=9D purposes like in our use case? > =20 > Here=E2=80=99s my rough suggestion =E2=80=93 probably wrong! My = additions unindented. > =20 > 3.1.3. Generate a JWS String > =20 > Use the result of the previous step as "JWS Payload" to the = signature > process described in Appendix F of JWS [RFC7515]. > =20 > In short a detached JWS is represented as the string concatenated from > =20 > BASE64URL(UTF8(JWS Protected Header)) || '.' || > || '.' || > BASE64URL(JWS Signature) > =20 > Notice, for comparison with the JWS Compact Serialization,=20 > that the JWS Payload is not included in the detached JWS String,=20 > but replaced by an empty string. > =20 > For the example, the JWS header is assumed to be: > =20 > {"alg":"HS256"} > =20 > The above example is equal to its own JCS canonicalization.=20 > JSON Canonicalization is not a requirement for the=20 > JWS Header, however this is RECOMMENDED, combined with > a fixed algorithm choice, if generating a consistent JWS/CT signature > that is s also to be used as as a canonical version identifier=20 > of the JSON payload content, e.g. as a strong ETag (RFC7232). > =20 > The JWS Signature of the canonicalized JSON payload, using the key=20 > specified in Section 3, is the bytes > =20 > 54 75 48 b4 20 42 6f c4 39 x8 8e 3d 8a 66 ab xe=20 > d2 5e 4b 11 f6 b8 b5 34 xe 1a 90 3f 96 63 c3 > =20 > =20 > Encoding as Base64 > =20 > The resulting concatenated JWS string should then read as follows: > =20 > eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4 > =20 > =20 > You may want to move my ETag recommendation to an appendix, as I = don=E2=80=99t feel it fits well where I put it, but I think it is worth = pointing out. As a use case. > =20 > I don=E2=80=99t know enough about RFC7515, is it possible to do = something like regular SHA3 or would my fingerprint use case need to = just publicly declare the signature key to use? > =20 > =20 > -- > Stian Soiland-Reyes, The University of Manchester > https://www.esciencelab.org.uk/ > https://orcid.org/0000-0001-9842-9718 = > Please note that I may work flexibly =E2=80=93 whilst it suits me = to email now, > I do not expect a response or action outside of your own working = hours. > =20 > =20 > From: art > on = behalf of Bret Jordan > > Date: Wednesday, 28 April 2021 at 03:29 > To: Dick Hardt > > Cc: "art@ietf.org " >, DISPATCH >, "rfc-ise@rfc-editor.org = " >, IETF SecDispatch > > Subject: Re: [art] Plain text JSON digital signatures > =20 > Luckily this time we have RFC8785 that solves the canonicalization = problem for JSON.=20 >=20 > Bret=20 >=20 > Sent from my Commodore 64 > =20 > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >=20 >=20 >> On Apr 27, 2021, at 7:39 PM, Dick Hardt > wrote: >>=20 >> I am supportive of this work, and would also be willing to work = towards a PS. I am seeing rapid growth in the demand to embed JWS in = JWS. >> =20 >> Given my experience with XML-DSig (see below) making it more XML-DSig = like does not sound like a good thing. >> =20 >> For any interested in some JWT history, when we were brewing up what = became OAuth 2.0, we did not want to tie a token format to the = implementation as many deployments had their own proprietary token = formats -- but we knew new deployments would benefit from standardizing = a token. >> =20 >> Our requirements were: >> - URL safe (access tokens at the time were often passed as a query = parameter -- I know, not the best idea, but working with what people = wanted) >> - HTTP header safe >> - richer than name / value pairs >> =20 >> Options we considered: >> ASN.1 - the 60s are calling and want their data back >> XML-DSig - not URL safe, large size, and I personally had many scars = canonicalizing XML. (An earlier company of mine had a contract to build = XML-DSig libraries for a few languages) >> =20 >> JSON was becoming very cool at that time, and with base 64 URL safe = encoding the string, it was URL safe, and treating the JSON text as = binary dealt with the canonicalization concerns -- and JSON = canonicalization did not exist. >> =20 >> Using a dot as the separator between header, payload, and signature = made it easy to parse. The dot was URL safe, but not in the base 64 set. >> =20 >> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >> =20 >> /Dick >> =20 >> =20 >> =20 >> =20 >> =E1=90=A7 >> =20 >> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan > wrote: >>> Dear Dispatch, >>>=20 >>> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID = for your consideration. This document describes how to use JWS and JCS = to create plain-text JSON signatures. The abstract reads as follows: >>>=20 >>> This document describes a method for extending the scope of the JSON = Web Signature (JWS) standard, called JWS/CT. By combining the detached = mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables = JSON objects to remain in the JSON format after being signed (aka "Clear = Text" signing). In addition to supporting a consistent data format, = this arrangement also simplifies documentation, debugging, and logging. = The ability to embed signed JSON objects in other JSON objects, makes = the use of counter-signatures straightforward. >>>=20 >>> The data tracker page for this: = https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ = >>>=20 >>> As you know there are large ecosystems that needs digital signatures = for plain text JSON data, meaning where the JSON data is not base64 = encoded. This ID provides a solution using existing IETF RFCs to make = this work. Further, this work looks to be adopted by many groups and = organizations from financial services, threat intelligence, and incident = response.=20 >>>=20 >>> We are not sure what direction would be best for this work in the = IETF, should we send to the ISE for publication or do you want to create = a working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct = >>> =20 >>> Thanks >>> Bret >>> =20 >>> --=20 >>> =20 >>> Sent from my TI-99/4A >>>=20 >>>=20 >>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >>> _______________________________________________ >>> art mailing list >>> art@ietf.org >>> https://www.ietf.org/mailman/listinfo/art = --Apple-Mail=_C2F3C8C4-DEFB-4D6B-A423-EA8BE3563CA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Stian. It would be great to use this in IEEE 2791. = Let's see what we need to do to make it more clear. 

Bret


On Apr 28, 2021, at 3:21 AM, Stian = Soiland-Reyes <soiland-reyes@manchester.ac.uk> wrote:

This draft is well written and = an approach we would like to use in IEEE 2791, and from your text it = will fit right into our =E2=80=9Cetag=E2=80=9D field where we hope for a = consistent hashing mechanism to detect changes.
 
The draft seems to build on JSON Web Signature (RFC7515) and JSON Web = Key (RFC7517), but the 3.1.3 is a bit too = brief for readers new to these standards, perhaps give a brief summary = for this example, especially as RFC7517 is quite comprehensive with many = options?
 
In particular it is unclear if the JWS Header also needs to = be JSON canonicalized =E2=80=93 which may be a good idea for consistent = =E2=80=9Chash=E2=80=9D purposes like in our use case?
 
Here=E2=80=99s my rough suggestion =E2=80=93 probably wrong! = My additions unindented.
 
3.1.3.  Generate a JWS String
 
   Use the result of the previous step as "JWS =
Payload" to the signature
   process described in Appendix F of =
JWS [RFC7515].
 
In short a detached JWS is represented as the string =
concatenated from
 
      BASE64URL(UTF8(JWS Protected =
Header)) || '.' ||
      || '.' ||
      BASE64URL(JWS Signature)
 
Notice,=
 for comparison with the JWS Compact Serialization, =

that the JWS Payload is not included in =
the detached JWS String, 
but replaced by =
an empty string.
 
   For the example, the =
JWS header is assumed to be:
 
   {"alg":"HS256"}
 
The =
above example is equal to its own JCS canonicalization. 
JSON =
Canonicalization is not a requirement for the 
JWS =
Header, however this is RECOMMENDED, combined with
a =
fixed algorithm choice, if generating a consistent JWS/CT signature
that =
is s also to be used as as a canonical version identifier 
of =
the JSON payload content, e.g. as a strong ETag (RFC7232).
 
The =
JWS Signature of the canonicalized JSON payload, using the key 
specified in Section 3, is the bytes
 
54 75 48 b4 20 42 6f c4 39 x8 = 8e 3d 8a 66 ab xe 
d2 5e 4b 11 f6 b8 b5 34 xe 1a = 90 3f 96 63 c3
 
 
Encoding as Base64
 
The =
resulting concatenated JWS string should then read as follows:
 
   =
eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4
 
 
You may want to move my ETag recommendation to an appendix, = as I don=E2=80=99t feel it fits well where I put it, but I think it is = worth pointing out. As a use case.
 
I don=E2=80=99t know enough about RFC7515, is it possible to = do something like regular SHA3 or would my fingerprint use case need to = just publicly declare the signature key to use?
 
 
--
Stian = Soiland-Reyes, The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/0000-0001-9842-9718
    Please note = that I may work flexibly =E2=80=93 whilst it suits me to email now,
    I do not = expect a response or action outside of your own working hours.
 
 
From: art <art-bounces@ietf.org> on = behalf of Bret Jordan <jordan.ietf@gmail.com>
Date: Wednesday, 28 April = 2021 at 03:29
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "art@ietf.org" <art@ietf.org>, DISPATCH <dispatch@ietf.org>, "rfc-ise@rfc-editor.org" = <rfc-ise@rfc-editor.org>, = IETF SecDispatch <Secdispatch@ietf.org>
Subject: Re: [art] Plain text = JSON digital signatures
 

Luckily this time we have RFC8785 that solves the = canonicalization problem for JSON. 

Bret 

Sent from my Commodore 64
 
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050


On Apr 27, 2021, at 7:39 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

I am = supportive of this work, and would also be willing to work towards a PS. = I am seeing rapid growth in the demand to embed JWS in JWS.
 
Given = my experience with XML-DSig (see below) making it more XML-DSig like = does not sound like a good thing.
 
For any interested in some JWT = history, when we were brewing up what became OAuth 2.0, we did not want = to tie a token format to the implementation as many deployments had = their own proprietary token formats -- but we knew new deployments would = benefit from standardizing a token.
 
Our = requirements were:
- URL safe (access tokens at the time were often = passed as a query parameter -- I know, not the best idea, but = working with what people wanted)
- HTTP = header safe
- richer than name / value pairs
 
Options we considered:
ASN.1 - the 60s are calling and want = their data back
XML-DSig - not URL safe, large size, and I = personally had many scars canonicalizing XML. (An earlier company of = mine had a contract to build XML-DSig libraries for a few languages)
 
JSON was = becoming very cool at that time, and with base 64 URL safe encoding the = string, it was URL safe, and treating the JSON text as binary dealt with = the canonicalization concerns -- and JSON canonicalization did not = exist.
 
Using a dot as the = separator between header, payload, and signature made it easy to = parse. The dot was URL safe, but not in the base 64 set.
 
And = Simple Web Tokens were born -- to be renamed JSON Web Tokens.
 
/Dick
 
 
 
 
3D"Image=E1=90=A7
 
On Tue, Apr 27, 2021 at = 8:28 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Dear = Dispatch,

Anders Rundgren, Samuel, Erdtman, = and I have been working on an ID for your consideration. This document = describes how to use JWS and JCS to create plain-text JSON signatures. = The abstract reads as follows:

This = document describes a method for extending the scope of the JSON Web = Signature (JWS) standard, called JWS/CT.  By combining the detached = mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables = JSON objects to remain in the JSON format after being signed (aka "Clear = Text" signing).  In addition to supporting a consistent data = format, this arrangement also simplifies documentation, debugging, and = logging.  The ability to embed signed JSON objects in other JSON = objects, makes the use of counter-signatures straightforward.

The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large ecosystems that = needs digital signatures for plain text JSON data, meaning where the = JSON data is not base64 encoded. This ID provides a solution using = existing IETF RFCs to make this work. Further, this work looks to be = adopted by many groups and organizations from financial services, threat = intelligence, and incident response. 

We are not sure what direction would be best for this work in = the IETF, should we send to the ISE for publication or do you want to = create a working group. Ultimately there is a lot of work that could be = done in this space to meet the needs of the market. We would be happy = with releasing these IDs for ISE publication, or for creating a working = group to move them forward. It is just important to note that the market = is in desperate need of these solutions. If you want to take it for a = spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct
 
Thanks
Bret
 
-- 
 
Sent from my TI-99/4A


PGP Fingerprint: 63B4 FC53 = 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
_______________________________________________art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art

= --Apple-Mail=_C2F3C8C4-DEFB-4D6B-A423-EA8BE3563CA4-- From nobody Wed Apr 28 19:06:29 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E715D3A2A28; Wed, 28 Apr 2021 19:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh24c09-M3sV; Wed, 28 Apr 2021 19:06:18 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 2C8EA3A2A29; Wed, 28 Apr 2021 19:06:18 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id 82-20020a1c01550000b0290142562ff7c9so5743699wmb.3; Wed, 28 Apr 2021 19:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zB0ww5WbhBaakRYwIOhQfl7GxxPU0HnZpVLdUTe2bpw=; b=KlUbK4R0H8N5BQB60zRLptIaYssejJdVeehs2P0uxyItN7izQCYJ0uGKfUVTG6xNsg V6Z2qyuKi0ACF2KdP2yVmbx7uAwCsnNlvbB9VMKkDjfeNiqD+PjmDlIr2P0oiydRA8ij BmYYR9l9d2/xnteAM6x4wQXma/eOICjRgIL5wrlPUEBe6RwfbAs3UZiVFwgpaVYodg+k XU3reMtet753lsblTev+ECtf6JD+Jm9aTj7NTldtvVA0tpmLb7anBx9Wn1lPykAutk97 zoKSveBw5H3gbnIE0cg7tLB9p2oaz0zNKACxNVuh2isd0zL5322w8WPltOSiksxw7pFZ LhWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zB0ww5WbhBaakRYwIOhQfl7GxxPU0HnZpVLdUTe2bpw=; b=pRpg8AHfHIOS2rdcZM+Li8hDKBqdZG/gZtWLoMzbljDuFhfekko56/epeHnHFN3eEv sP4X4rTQszZeF4K7e2rdeaD0zZ0/RKb026UAwgJOSsYf0pPZh/6dJ/iMmW/Zz4w7+cAj wS+ZT0MqkDjoPJ3RPjlZPCjKxipUqh/TBhgsQaD85FStIDmefv9sor16nt99atF6tqDX xTAmDHoMtudG4ND3Blimxpga0rRg9Mm8F9BZD/15IwvPk5DfCSvLlS+lt9L0SPYle87Z 1wq4sh5DMmUagx368K4Hdq3u9HnA/PDKKaEyfQYNxaCqBFbmATiqdnVW7bQ+/piCmVf+ RwZw== X-Gm-Message-State: AOAM53293mLrtgrmiv67Yxce18iBB53qbvSYUSdhlJoTOf7H6f3gn9TH vxK5TqkNS1jV1S1/aHCLqwg= X-Google-Smtp-Source: ABdhPJwZwkI1+ZXOe+86em7xU7ja7BM81TY4BFYLU79ru4pJat53wUwZDasxenyVSiqd2/ULYSdFxw== X-Received: by 2002:a05:600c:4f14:: with SMTP id l20mr4535486wmq.150.1619661974798; Wed, 28 Apr 2021 19:06:14 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id q20sm13657783wmq.2.2021.04.28.19.06.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Apr 2021 19:06:14 -0700 (PDT) To: Stefan Santesson Cc: DISPATCH , art@ietf.org, IETF SecDispatch , rfc-ise@rfc-editor.org References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> From: Anders Rundgren Message-ID: Date: Thu, 29 Apr 2021 04:06:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] [Secdispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 02:06:23 -0000 On 2021-04-28 11:29, Stefan Santesson wrote: > RFC 7797 is supported by common open source such as Nimbus and I use it > for instances where you obviously do not need a URL safe token. I see. > As such it works for JWS but Not for JWT. But It works really well and > saves space when URL safeness is not needed. That's great. Note though that this scheme require that '.' are escaped into \u002e as can be seen in the example below. Data to sign: { "payee": "Space Shop", "amount": { "currency": "EUR", "value": "100.00" } } Using RFC 7797 (with "b64":false,"crit":["b64"]): eyJhbGciOiJFUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19.{"amount":{"currency":"EUR","value":"100\u002e00"},"payee":"Space Shop"}.KFOhCfpyZnW7RUpwOvZAJPKDfpF1R2uENirUW6Ew4v1HwQI5iFJaXKW0PsvTuVNpb-T_UjpOcv868qihMjeMwA Using JWS/CT (here pretty-printed using standard JSON tools): { "payee": "Space Shop", "amount": { "currency": "EUR", "value": "100.00" }, "signature": "eyJhbGciOiJFUzI1NiJ9..aY27xoS5B3J-uZtUdJzXevqBbnNf4vNT1YN1_eHPOcILMXlVu3VjdExW17f66EGdt4mxQSnpAVLsUa4k2zSLQw" } > So I guess your answer is that it still encapsulates the signed JSON in > the signature, and that the proposal really is about embedding signature > in the JSON object being signed (and not about whether the JSON is in > plaintext). JWS/CT addresses several issues: - Maintaining a consistent message structure - Maintaining JSON notation - Full compliance with JavaScript and browser APIs (including the "JSON" object). However, from an IETF adoption point of view it is rather the validity and reliance on RFC 8785 that is the core issue. > Could you elaborate why you think it is important to NOT embed signed > data in the signature? The example above may serve this purpose. > What is the usecase? See this response to Carsten: https://mailarchive.ietf.org/arch/msg/dispatch/3EX1uM9K_oCft7BoQfW3EQj_En4/ thanx, Anders > > /Stefan > > > On 2021-04-28 11:00, Anders Rundgren wrote: >> On 2021-04-28 8:52, Stefan Santesson wrote: >>> How is this different/better than implementing RFC 7797 and apply the >>> header b64=false in order to carry plaintext JSON in the payload? >> >> Good question! >> >> Apart from the fact that the data becomes embedded in the JWS >> signature container (=changing the structure), you cannot really put >> JSON there: >> https://tools.ietf.org/html/rfc7797#section-5.2 >> >> My guess that the only real-world use of this option is to save an >> internal-only (but technically redundant) Base64Url-operation for >> truly detached data, be it it JSON, PNG, etc. >> >> JWS/CT was designed for signing JSON Objects ({}), and let them remain >> as such. >> >> Thanx, >> Anders >> From jzern@google.com Thu Apr 29 19:58:30 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CD83A0402 for ; Thu, 29 Apr 2021 19:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipwynRLLU807 for ; Thu, 29 Apr 2021 19:58:28 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 170FF3A03F6 for ; Thu, 29 Apr 2021 19:58:27 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id b21so6516324ljf.11 for ; Thu, 29 Apr 2021 19:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pIB8zsWIgLdd46skuE4AaYTXnDzvOXUWKzn9dp+v6R4=; b=ufUKDPGgEwrsNvC+jbWCe0XP9WNg6agnesk5v/KHbkls/BVI3eBXDfOLqKlFD2sxLP 8wkGqzn4JTPzqJdIN8I+TLas0f2wJMRbHN8q7vuXGii22s2Ut9UmnYqa/tSE2bk3P9ia N8F8aEkTPlZSp1bL8cwHwvyUOxlJKTD4zFAE+Sw3psHxONq5/eJL6yOUyw9M42Pd/ayG dSI/3ldGwH5sEGziQ8aFpbgh+9b+Ch4O63n7Ax7Eav2XqZxM4xxWE6Af21smuGQswufN 2/CILDBwOmSwolJEwNBE0t9wcmU2DtVfEdB8qzwp3pxD351rRADXY6IMYPpVoiYq16am qLFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pIB8zsWIgLdd46skuE4AaYTXnDzvOXUWKzn9dp+v6R4=; b=sqvtUbGSH961owhZbnIPwHelwM4aakayhCzEJLEWYApkLXQQOKAheAvcu/1rnoMG9j S8b8dKYPOF7IZUxBIyb2yL68p+w0JelcpTlkHyEVRgCi/YAZQU9mDlyi5oZQLx7Yswd+ 87W89UxJRf4iJB6+TU2zWuJUfLN0PAln60yQsJUjQiBHX5GVq3Hk+MszvQJZ4NdV3738 MScDV54VuZYMLvw8ZPDRR6xyTqdADZnALNmByd4JI85d5/9NTDBlvhFkh7yYbeoQAPFG nH8wP2OaR3IsD9+GkvSMeRBMOR9ZsIIaTvWQEDbs52RrFm5u+bcVbJzqWnFuHku/vtZ9 /6Ag== X-Gm-Message-State: AOAM530/BSdZLKGbuUuc4QC1ME5HYJ8GlRSbX2RYjXitUoOxxGV+yy8t o0Uk17QAmPb4uEIHvQIWHWk1Tdc9aiDqIyuKa8btI4+DuXMZE6O6 X-Google-Smtp-Source: ABdhPJxZGmI7ITWHiM8ws1hImNIkV2IyzQ/09F6uYStWHUAQ56Vym/vyH/eSWh1hl8tiJMIpkls5/kjIySf5E8/ymQc= X-Received: by 2002:a2e:9549:: with SMTP id t9mr1945343ljh.292.1619751502979; Thu, 29 Apr 2021 19:58:22 -0700 (PDT) MIME-Version: 1.0 From: James Zern Date: Thu, 29 Apr 2021 19:58:11 -0700 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000f6126005c127c8dc" Archived-At: X-Mailman-Approved-At: Fri, 30 Apr 2021 07:32:02 -0700 Subject: [dispatch] processing path for image/webp rfc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 03:01:07 -0000 --000000000000f6126005c127c8dc Content-Type: text/plain; charset="UTF-8" It was suggested I post a message here requesting advice on the processing path of my submission to register the image/webp mime-type [1]. I'm not familiar with the process, so if you could have a look and see if this is appropriate for the DISPATCH working group or suggest another I'd appreciate it. [1] https://datatracker.ietf.org/doc/draft-zern-webp/ --000000000000f6126005c127c8dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It was suggested I post a message here requesting advice o= n the processing path of my submission to register the image/webp mime-type= [1]. I'm not familiar with the process, so if you could have a look an= d see if this is appropriate for the DISPATCH working group or suggest anot= her I'd appreciate it.

--000000000000f6126005c127c8dc-- From nobody Fri Apr 30 13:17:05 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC583A257D; Fri, 30 Apr 2021 13:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g3PNRDuEJ-2; Fri, 30 Apr 2021 13:16:59 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2052.outbound.protection.outlook.com [40.107.21.52]) (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 A5BEE3A257B; Fri, 30 Apr 2021 13:16:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eGmPH37DGR0WL0TgOkZBK36Ek+DhsZ47zGLF/Jq3zhJ3uTJBRPrbfT45tVdWbveyXgwWqUIhljcv1ygMtSjtXRMRVqM3RQs+p8QT7Zun1sow+IlH+D0o9ZBdgE+TQlzgZSTlOAsthLn4onsLz5/UkjCUJd+TxRXS96PazF1wXNWBLbXmh9L7H5SHKILFoTlUaza2rC5wzYyCg2hkPigbYCoPHZbnNSCMix5iPGQJrZ5QvFLy0FB8Jlo6WHFyfougcro6Lxg6cqqENYb6vkZFP8rTNgVRJKyYsjngxcc6ugltGIdBL06DLau8qldOuRttfBfDN+klzdzAmnhT3/Fv1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xTMf9EwkHRuOHHhjNb50AMpu5GzLIKnJqHTqPOMEwyA=; b=YeYIY44Auf9KA1ACv46nVKUGaHkcgwEfD1QpaibyVOaBJUoBXa6oWFGws89aeF8/7UbkNSXbv7ycxQP9TpSo0tJJzM9S3TV1fyn4zcO5RwtgbuqPQjGRGPRtUUOAhg4FFaZ0vHeM01L6g0a0a/nNIg8/5anjiy3MhWSL/NqHuu2B3LZa2VzvsHPF2xpjTDpGQd/fAIQ4W9wOGYNsokPT3zxilzmtvB0G7+ph3fdGjqiTBb+7iBbxu7ShKieql9xe6cD4gNqHqDFyw2eJ7CqwKGlW4bM0wwz2cb88E/qOp7vaXOr10CYtLt4+gph96kePXSDNiPr4kL3Fq8/BJ7vvuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xTMf9EwkHRuOHHhjNb50AMpu5GzLIKnJqHTqPOMEwyA=; b=PlaJ9Hop5q+8xNbF6n+VVzMrZreCpGrYLle/FI21Fx/GzUU6vXF6fdYw3TQgzf3MF87VShGzV2Z7fjXREzmKhzdQI2kz7zJmRIjFnL7IiPnNfFh1a6ixTMiW/uWUxvNikaZfQ0w6C/jz+Vih/au/cFENUB33k7d3CMOPf2ym5wc= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2569.eurprd07.prod.outlook.com (2603:10a6:3:98::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.14; Fri, 30 Apr 2021 20:16:53 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b%5]) with mapi id 15.20.4108.017; Fri, 30 Apr 2021 20:16:53 +0000 From: Francesca Palombini To: "dispatch@ietf.org" CC: ART ADs , Bron Gondwana Thread-Topic: [dispatch] Proposed charter for extended date format Thread-Index: AQHXMUdf5/iMRepR0UalfMEr0odfGaq0SH6AgAkk8oCAACbUAIAQJjUA Date: Fri, 30 Apr 2021 20:16:52 +0000 Message-ID: References: <9e1bc197-19d5-44d1-867f-6d35108d63ae@dogfood.fastmail.com> <3767E6D1-7EC1-4163-B099-E68EE1C7FFDD@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:eb00:accc:c516:c7b2:7be] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c756cc3-862d-4063-23ce-08d90c14e4fe x-ms-traffictypediagnostic: HE1PR0701MB2569: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fffSnpV8UrtLnoe/Z5mh6IQNAc9PoPjEr+SoikydmO62o+Jo2k5RkpFNCHZNDmmKTkLlTlh3bHz6Ct+USNJ80T7TwbnOEftpenzzf6n+nAZ614AWN74aC/O1qtoG0/6hwTewE0e5XL8cAbAaW6mX2zUS9pV9MuwxavaWX8a97b1J5KEpwktzTxkl9HHZpcyhHQEq1CWvMT705Fw3Tgjta53+ATZAkoz18NPvBpJgwZUIdLa4YpZiUvqwv+ZpJYn572nfkeRXtOFjuQXfy5J+ekei7T69PVYqhdOdF6Maf9Qb3qu7C7pg4RXMkh+P7PJuibiMlya/X4vNeuzg/8CZIT1buKMzNeh0Gyr7Aj8P6XM7P+UjIKQSHhcA1FVmTYGwsBin8ThuqXywi25zCuDqRIRhHiIr88wXrg8Kdy1iStd3HeptQAJr09FlQEO4bT0UQo1hO7p3u6Sf7GXTRuNbOjtV6NS3q5ZjdW3q1JIz+HF6gjGiSLs9A/1MrL0427cmpc8pkzJCQlYIMNFtfGUUkzIFvNlVY71IRTpK14QDSqpD+igR7ARg8zyTkhyKoHNPhD67KLmgk3r6mvzRtKmutlMP/lBgDuQc1vYit6ROAv5iK74ifr90u0hTy3MeNPrclbhogGQX9zXkq7YtCwvqEsYjIG4K3gyoqdOa5YA93L+Gjo1STCbZ5ZD9wos2AXtGwld+YSd0uAHQdn1GQVVUjXdTmuYj+5iieR3aH+3UZPY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(366004)(376002)(136003)(346002)(5660300002)(66556008)(166002)(64756008)(54906003)(8676002)(6486002)(53546011)(2616005)(6506007)(478600001)(966005)(38100700002)(4326008)(122000001)(316002)(66446008)(66946007)(83380400001)(71200400001)(76116006)(186003)(66476007)(33656002)(36756003)(8936002)(44832011)(2906002)(6512007)(86362001)(6916009)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?aU5Oc0tENHQzemhoRVhtWW50VzdaK1poanp1Q2ZwUlN1REZzUFhqL0hCU0p2?= =?utf-8?B?V1QwY015ZGdxNC9ER1hnOEN0VGtRNXY0cWcyMjdMMmFkTnFKN3JtaXBvSVF4?= =?utf-8?B?RGJnUGVIcVNYTW1EREx0bWY3VHBQS2JZeTZVUzY4MHJsVUIxU1VTVk5tVkpF?= =?utf-8?B?WGJPYU04Y2ZiOWFZbm5jNTV4WjJ4QXlaSnk3c284S05UNFM5N3l6SVVyWGo1?= =?utf-8?B?S2IvYzI1WXo5RWdPQ0ZhSkFlK0pWYXduRkhtZGZldllDaWtMT25NckRJQW93?= =?utf-8?B?b0xDbGM4Q3B4Nm4xUkh0YUJKUWZqeEdzSlJBd1gwOFdNRHdNK2ZOMXNVdGZV?= =?utf-8?B?U0JQKzJoMDg3cU1KQ1FDZGFjSGZNWDRCSG10R0g1S25oeHl5MDJXQ3lWRlBV?= =?utf-8?B?eWVPY05ZeVV0TlB5bHEyelF0cWZUUXVvTXhPMDJVQjhYZWpPc3NxeWFPdjdH?= =?utf-8?B?TmxWeGdyL2RKNzdpR0U3d2R1MVJCeGl6MXhBTXM0Z2xaMytWTHZBdzNheXlT?= =?utf-8?B?aGJkakxHdUdjLzJyV3hHRHA1WjlKeFYrbi9SRjBqUEhQdlhlUm1Kak1yb0po?= =?utf-8?B?NVFkd1Q1SEhQc3pTdnZUdjZRN3JwU1F2Tys3Z21mOTM5NGFsajZCSVBaNkFn?= =?utf-8?B?blNlM2QvVTdJNU10NVo4OFpIQlRsZk1La3ZiaUVMN1F6RVFwdUpvbEYxTTBo?= =?utf-8?B?ZFNtalhza2Iwa1RWYkd5NkRRQm9pRmc3RnV6QnY3U3g3cTJMcStrWkxQWENj?= =?utf-8?B?cHkxa0NQNGNnYmcrdVpLdk1xa0pvcnNkMGhMUERHVHpPY0VwQmQxT0pNNXRu?= =?utf-8?B?SW9nNkRJQmc0S2lOanFzRkRIbFZKOHpXSjRKVHR4UWVsb1RNTGZJVkN3Z0ZX?= =?utf-8?B?SlVreTlCckNXaTNrNzJhbzZPRE44ZlpYckN2ZVB5RnJzZW14YXBCeDNzNHhq?= =?utf-8?B?V2E4YjZDUHlvM0JJcUNsYUF6cnE4L2xLSU1LbWVUZzRWYktqOVc5bVNNVXd5?= =?utf-8?B?YklPSWpoMWp1VFBuM1BIRTJoNjdNU1hFeFVCS2VDSndZcVV3SWhPTTFzR0I2?= =?utf-8?B?cjMxRE13ZTI1M0FPQ1R6c1NxQlpBVGZ2MGNuY0tFOU5vTW55eHBxNE9jZE5k?= =?utf-8?B?MG5oaFJKQmZ3Q2xweHFLTmJZV1pVNFZQaHFJQkhxV280OWkxdFQ4WEF0ckQ4?= =?utf-8?B?TTBoeWg3TFY0ZnRYSkoyR1BoNmZMVjNlY25VL3doMWQrVHVYNzRhV1JIeGFt?= =?utf-8?B?S2pmR1VPQU0yb3JSSHNzS1RNdFZhU1V6WTdCbHNVNlVURWxIZXlUWm9tMnZB?= =?utf-8?B?bS9PaklnNmNLR1Z5bkxOK0FIWVZrMVJ1SjlNajEwWXQwNjcwQ2hBZkcyblp2?= =?utf-8?B?S1lWajkwMTNNd1ZTcm45M2pNbjZONE9GejA2ZmlLeEVpdllNUEg0OFRPOUEw?= =?utf-8?B?ajF0aE93MWN2QktZNWpNcGxvVjJ5akZscFZaVHRmY1Nqa05peUE1TVU2TXBJ?= =?utf-8?B?RzR5dXRLZm1OU0EwWGlHeVg0UTE3UWFBa3FlYk9BM003a093MXpLa2l5bndp?= =?utf-8?B?SEhjTm1QSnlGWkUyeitmY0I2NWQ4QkoxNnVTMFp3QjNLemx0Q1daVngwV0d5?= =?utf-8?B?N2ZTTnRRTXFRSlRyOUJvZUtNRUVKZDFxTDQ2ZWlKSGdrT05iWnNtakNIR3VG?= =?utf-8?B?V09iZkRweXRheVFqelJFbUdXdC9oZzlUZ2ZXMkpnVzJMdUdFWWluKzQzNUYy?= =?utf-8?B?RHlkMjE3KzFWUk80M2lOWUxZMDBFSXhZdFNucFZQd0t6dzlhZU50aHppVHZw?= =?utf-8?B?MzZTSG9WdGh6RWxUQkZxd016cHhnV1g3SFdqVEk0VEhPU1l0SUV3ODBLTlVV?= =?utf-8?B?MmpCTlN4RmNMS0ZCVUN2L0JhRDUrcjd0cE9UdGJWNktwT3c9PQ==?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F8A42AE089534C0093E3FE62DA41F64Dericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c756cc3-862d-4063-23ce-08d90c14e4fe X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2021 20:16:52.9206 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RVuA8JLVhXbxR2sTrP5fsVX6wMxvUXqFHczz9qy9cCia/ei2uCv1N/Wx83X+ynJOkXDPYhVGiU76Aq3ravayuzpFSQZe55ynsYjfn/zHPz/qF1ThKq0IiNHh0bVxEgFQ X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2569 Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format 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, 30 Apr 2021 20:17:04 -0000 --_000_F8A42AE089534C0093E3FE62DA41F64Dericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGFua3MgZm9yIHRoZSB1c2VmdWwgZGlzY3Vzc2lvbiwgYW5kIHRoYW5rcyBC cm9uIGZvciBkcmFmdGluZyBhIHByb3Bvc2FsIGNoYXJ0ZXIgdGV4dC4gVGhlIG5leHQgc3RlcHMg YXJlIGZvciBtZSB0byByZXF1ZXN0IGNyZWF0aW9uIG9mIGEgbmV3IG1haWxpbmcgbGlzdCAod2hp Y2ggd2lsbCBiZWNvbWUgdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0KSBhbmQgc3RhcnQg dGhlIG9mZmljaWFsIGNoYXJ0ZXJpbmcgcHJvY2Vzcy4gQXMgYSBoZWFkcyB1cCwgd2Ugd2lsbCBi ZSBsb29raW5nIGZvciB2b2x1bnRlZXJzIHRvIGNoYWlyIHRoaXMgd29ya2luZyBncm91cCwgc28g aWYgeW91IGFyZSB3aWxsaW5nIHRvIHNlcnZlLCBvciB5b3UgaGF2ZSBzb21lb25lIGluIG1pbmQg d2hvIHlvdSBiZWxpZXZlIHdvdWxkIGZpdCBpbiB0aGUgcm9sZSwgcGxlYXNlIGxldCB1cyBrbm93 Lg0KSeKAmWxsIGFsc28gcmVhY2ggb3V0IHRvIEVDTUEgVEMzOSBjaGFpcnMgYW5kIElTTyBUQyAx NTQgdG8gbWFrZSBzdXJlIHRoZSBlZmZvcnQgaXMgY29vcmRpbmF0ZWQuDQoNCg0KRnJhbmNlc2Nh DQoNCkZyb206IGRpc3BhdGNoIDxkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg b2YgU2hhbmUgQ2FyciA8c2ZmYz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBU dWVzZGF5LCAyMCBBcHJpbCAyMDIxIGF0IDE4OjE0DQpUbzogRWxpb3QgTGVhciA8bGVhckBjaXNj by5jb20+DQpDYzogImRpc3BhdGNoQGlldGYub3JnIiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+LCBVamp3 YWwgU2hhcm1hIDx1c2hhcm1hQGlnYWxpYS5jb20+LCBFbGlvdCBMZWFyIDxsZWFyPTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gUHJvcG9zZWQgY2hh cnRlciBmb3IgZXh0ZW5kZWQgZGF0ZSBmb3JtYXQNCg0KSSBhbSBsb29raW5nIGZvcndhcmQgdG8g c2VlaW5nIHRoZSBjaGFydGVyIGZvciB0aGlzIFdHIGFkb3B0ZWQsIHNvIHRoYXQgd2UgY2FuIHdv cmsgb24gdGhlIHN1YnN0YW50aXZlIGlzc3VlcyBpbiB0aGF0IGZvcnVtLiAgV2hhdCBhcmUgdGhl IG5leHQgc3RlcHMgdG8gYWRvcHQgdGhlIGNoYXJ0ZXI/DQoNCg0KT24gVHVlLCBBcHIgMjAsIDIw MjEgYXQgODoyMSBBTSBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbTxtYWlsdG86bGVhckBjaXNj by5jb20+PiB3cm90ZToNCkp1c3QgdG8gZm9sbG93IHVwIG9uIHRoaXMsIGluIGNhc2UgdGhlcmUg aXMgYW55IHF1ZXN0aW9uIG9yIGlmIGFueW9uZSBpcyBrZWVwaW5nIHNjb3JlLCBteSBxdWVzdGlv biBoYXMgYmVlbiBhbnN3ZXJlZCB0byBteSBzYXRpc2ZhY3Rpb24gYW5kIEkgc3VwcG9ydCB0aGlz IHdvcmsgcHJvY2VlZGluZy4NCg0KRWxpb3QNCg0KDQpPbiAxNCBBcHIgMjAyMSwgYXQgMTk6NDIs IEVsaW90IExlYXIgPGxlYXI9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmxlYXI9 NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KU2lnbmVkIFBHUCBwYXJ0DQpK dXN0IG9uZSBxdWVzdGlvbjoNCg0KSXMgaXQgbmVjZXNzYXJ5IGZvciBib3RoIHRoZSBJRVRGIGFu ZCBUQzM5IHRvIHN0YW5kYXJkaXplIHRoaXM/DQoNCkVsaW90DQoNCg0KT24gMTQgQXByIDIwMjEs IGF0IDE4OjAwLCBCcm9uIEdvbmR3YW5hIDxicm9uZ0BmYXN0bWFpbHRlYW0uY29tPG1haWx0bzpi cm9uZ0BmYXN0bWFpbHRlYW0uY29tPj4gd3JvdGU6DQoNClRoaXMgd2FzIGRpc2N1c3NlZCBpbiB0 aGUgRElTUEFUQ0ggbWVldGluZyBhdCBJRVRGMTEwOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9taW51dGVzLTExMC1kaXNwYXRjaC8NCg0KVGhlIGNvbmNsdXNpb24gb2YgdGhlIGRp c2N1c3Npb24gd2FzOg0KDQoNCiogS2lyc3R5IChjaGFpcik6IFNvdW5kcyBsaWtlIHRoZXJlJ3Mg Z2VuZXJhbCBhZ3JlZW1lbnQgdGhhdCBhIHdvcmtpbmcgZ3JvdXAgaXMNCg0Kd2hhdCdzIG5lZWRl ZCwgd2Ugd2lsbCB0YWtlIGEgZmluYWwgZGVjaXNpb24gb24gdGhlIGxpc3QgYW5kIGp1c3QgY29u ZmlybSB3aXRoDQoNClBhdHJpY2sgYXMgY28tY2hhaXIgYmVmb3JlIG9mZmljaWFsbHkgZGlzcGF0 Y2hpbmcgYXMgc3VjaC4gVGhlIGxpbmsgdG8gdGhlDQoNCmNoYXJ0ZXIgaXMgb24gbGlzdCB0b28s IHBsZWFzZSB0YWtlIGEgbG9vayBhbmQgc2VlIGlmIHlvdSB0aGluayBhIEJvRiBpcyBuZWVkZWQN Cg0KYXMgdGhlIG5leHQgc3RlcCBvciBhIFdHIGNhbiBiZWdpbiByaWdodCBhd2F5Lg0KDQpTbyBN dXJyYXkgKEFEKSwgZG8geW91IHRoaW5rIHdlIGhhdmUgZW5vdWdoIHRvIHJlcXVlc3QgYSB3b3Jr aW5nIGdyb3VwIGJlIGNoYXJ0ZWQgZnJvbSB0aGUgZGlzY3Vzc2lvbiBhbmQgdGhlIHByb3Bvc2Vk IGNoYXJ0ZXIgdGV4dCBxdW90ZWQgYmVsb3c/DQoNClRoYW5rcywNCg0KQnJvbi4NCg0KT24gRnJp LCBGZWIgMTksIDIwMjEsIGF0IDE1OjIwLCBCcm9uIEdvbmR3YW5hIHdyb3RlOg0KSSd2ZSBhc2tl ZCB0aGUgY2hhaXJzIGZvciBzcGFjZSBvbiB0aGUgbmV4dCBkaXNwYXRjaCBhZ2VuZGEgdG8gdGFs ayBhYm91dCBkaXNwYXRjaCBmb3INCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcnl6b2t1a2VuLWRhdGV0aW1lLWV4dGVuZGVkLw0KDQpUaGUgYXV0aG9ycyBoYXZlIHRh a2VuIG9uIGJvYXJkIHRoZSBpZGVhIHRoYXQgd2Ugc2hvdWxkIGV4dHJhY3QgdGhlICJvYnNvbGV0 ZSBSRkMzMzM5IiBhbmQgZWl0aGVyIHJlbW92ZSBpdCBlbnRpcmVseSwgb3Igc2VwYXJhdGUgaXQg aW50byBhIGRvY3VtZW50IHdoaWNoIGRvZXMgbm90aGluZyBidXQgdXBkYXRlIFJGQzMzMzkgd2l0 aCBzdXBwb3J0IGZvciBhIHdpZGVyIHJhbmdlIG9mIHllYXIgdmFsdWVzLiAgVGhlcmUgd2lsbCBi ZSBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdCBzb29uLg0KDQpUaGUgZGlzcGF0Y2gg Y2hhaXJzIGFsc28gYXNrZWQgbWUgZm9yIHNvbWUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0IGlmIHdl IHdlcmUgdG8gc3BpbiB1cCBhIHdvcmtpbmcgZ3JvdXAgZm9yIHRoaXMgdG9waWMuICBIZXJlJ3Mg dGhhdCB0ZXh0Lg0KDQpDaGVlcnMsDQoNCkJyb24uDQoNClNlcmlhbGlzaW5nIEV4dGVuZGVkIERh dGEgQWJvdXQgVGltZXMgYW5kIEV2ZW50cyAoU0VEQVRFKQ0KLS0tLQ0KDQpSRkMzMzM5IGRlZmlu ZXMgYSBmb3JtYXQgdGhhdCBjYW4gcmVsaWFibHkgZXhwcmVzcyBhbiBpbnN0YW50IGluIHRpbWUs IGVpdGhlciBpbiBVVEMgb3IgaW4gYSBsb2NhbCB0aW1lIGFsb25nIHdpdGggdGhlIG9mZnNldCBh Z2FpbnN0IFVUQywgaG93ZXZlciBkYXRldGltZSBkYXRhIG9mdGVuIGhhcyBhZGRpdGlvbmFsIGNv bnRleHQsIHN1Y2ggYXMgdGhlIHRpbWV6b25lIG9yIGNhbGVuZGFyIHN5c3RlbSB0aGF0IHdhcyBp biB1c2Ugd2hlbiB0aGF0IGluc3RhbnQgd2FzIHJlY29yZGVkLiBQYXJ0aWN1bGFybHkgd2hlbiB1 c2luZyB0aW1lcyBmb3IgaW50ZXJ2YWwsIHJlY3VycmVuY2UsIG9yIG9mZnNldCBjYWxjdWxhdGlv bnMsIGl0J3MgbmVjZXNzYXJ5IHRvIGtub3cgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhlIHRpbWVw b2ludCBleGlzdHMuDQoNCkl0IGlzIHZhbHVhYmxlIHRvIGhhdmUgYSBzZXJpYWxpc2F0aW9uIGZv cm1hdCB3aGljaCByZXRhaW5zIHRoaXMgY29udGV4dCBhbmQgY2FuIHJlbGlhYmx5IHJvdW5kLXRy aXAgdGhlIGFkZGl0aW9uYWwgY29udGV4dCB0byBzeXN0ZW1zIHdoaWNoIHVuZGVyc3RhbmQgaXQs IHZpYSBpbnRlcm1lZGlhdGUgc3lzdGVtcyB3aGljaCBvbmx5IG5lZWQgdG8ga25vdyBhYm91dCB0 aGUgaW5zdGFudCBpbiB0aW1lLg0KDQpUaGUgVEMzOSB3b3JraW5nIGdyb3VwIGF0IEVDTUEgaGF2 ZSBkZXZlbG9wZWQgYSBmb3JtYXQgd2hpY2ggaXMgYSBnb29kIGJhc2lzIGZvciB0aGlzIHdvcmsu DQoNCkl0IGlzIGFudGljaXBhdGVkIHRoYXQgdGhpcyBkb2N1bWVudCB3b3VsZCBiZSBhIGNvbXBh bmlvbiB0byBSRkMzMzM5IHJhdGhlciB0aGFuIGEgcmVwbGFjZW1lbnQsIGVtYmVkZGluZyBhbiB1 bi1hbHRlcmVkIFJGQzMzMzkgaW5zdGFudCBhbG9uZyB3aXRoIHRoZSBjb250ZXh0dWFsIGRhdGEu DQoNCkl0IGlzIGFsc28gd2l0aGluIHNjb3BlIGZvciB0aGlzIGdyb3VwIHRvIGNvbnNpZGVyIGEg bWlub3IgdXBkYXRlIHRvIFJGQzMzMzkgdG8gYWxsb3cgbGFyZ2VyIHRoYW4gNCBkaWdpdCBzaWdu ZWQgeWVhcnMsIHRvIGVuYWJsZSByZXByZXNlbnRpbmcgdGltZXMgZnVydGhlciBpbnRvIHRoZSBw YXN0IGFuZCBmdXR1cmUuDQoNCk9uY2UgdGhpcyB3b3JrIGlzIGRvbmUgaXQgaXMgYW50aWNpcGF0 ZWQgdGhhdCB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSBzaG9ydC1saXZlZCwgYW5kIG9uY2Ug dGhlIG9uZSBvciB0d28gZG9jdW1lbnRzIGFyZSBwdWJsaXNoZWQgdGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBjbG9zZSBkb3duLg0KDQpNaWxlc3RvbmVzOg0KKiBBcHJpbCAyMDIxOiBBZG9wdCBkcmFm dCBkZXNjcmliaW5nIGEgc2VyaWFsaXNhdGlvbiBmb3JtYXQgZm9yIGV4dGVuZGVkIGRhdGV0aW1l cy4NCiogSnVseSAyMDIxOiBTdWJtaXQgdGhlIHNlcmlhbGlzYXRpb24gZG9jdW1lbnQgdG8gdGhl IElFU0cuDQoNCi0tDQogIEJyb24gR29uZHdhbmEsIENFTywgRmFzdG1haWwgUHR5IEx0ZA0KICBi cm9uZ0BmYXN0bWFpbHRlYW0uY29tPG1haWx0bzpicm9uZ0BmYXN0bWFpbHRlYW0uY29tPg0KDQoN Cg0KLS0NCiAgQnJvbiBHb25kd2FuYSwgQ0VPLCBGYXN0bWFpbCBQdHkgTHRkDQogIGJyb25nQGZh c3RtYWlsdGVhbS5jb208bWFpbHRvOmJyb25nQGZhc3RtYWlsdGVhbS5jb20+DQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxp bmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KDQoNCg0K --_000_F8A42AE089534C0093E3FE62DA41F64Dericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sbzsNCglwYW5vc2UtMToyIDExIDYgOSAzIDggNCAyIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgdGhl IHVzZWZ1bCBkaXNjdXNzaW9uLCBhbmQgdGhhbmtzIEJyb24gZm9yIGRyYWZ0aW5nIGEgcHJvcG9z YWwgY2hhcnRlciB0ZXh0LiBUaGUgbmV4dCBzdGVwcyBhcmUgZm9yIG1lIHRvIHJlcXVlc3QgY3Jl YXRpb24gb2YgYSBuZXcgbWFpbGluZyBsaXN0ICh3aGljaCB3aWxsIGJlY29tZSB0aGUgd29ya2lu ZyBncm91cCBtYWlsaW5nDQogbGlzdCkgYW5kIHN0YXJ0IHRoZSBvZmZpY2lhbCBjaGFydGVyaW5n IHByb2Nlc3MuIEFzIGEgaGVhZHMgdXAsIHdlIHdpbGwgYmUgbG9va2luZyBmb3Igdm9sdW50ZWVy cyB0byBjaGFpciB0aGlzIHdvcmtpbmcgZ3JvdXAsIHNvIGlmIHlvdSBhcmUgd2lsbGluZyB0byBz ZXJ2ZSwgb3IgeW91IGhhdmUgc29tZW9uZSBpbiBtaW5kIHdobyB5b3UgYmVsaWV2ZSB3b3VsZCBm aXQgaW4gdGhlIHJvbGUsIHBsZWFzZSBsZXQgdXMga25vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPknigJlsbCBhbHNvIHJlYWNoIG91dCB0byBFQ01BIFRDMzkgY2hhaXJzIGFuZCBJU08g VEMgMTU0IHRvIG1ha2Ugc3VyZSB0aGUgZWZmb3J0IGlzIGNvb3JkaW5hdGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YnI+ DQpGcmFuY2VzY2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+ZGlzcGF0Y2ggJmx0O2Rpc3BhdGNoLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBTaGFuZSBDYXJyICZsdDtzZmZjPTQwZ29vZ2xlLmNvbUBk bWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgMjAgQXByaWwgMjAy MSBhdCAxODoxNDxicj4NCjxiPlRvOiA8L2I+RWxpb3QgTGVhciAmbHQ7bGVhckBjaXNjby5jb20m Z3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtkaXNwYXRjaEBpZXRmLm9yZyZxdW90OyAmbHQ7ZGlz cGF0Y2hAaWV0Zi5vcmcmZ3Q7LCBVamp3YWwgU2hhcm1hICZsdDt1c2hhcm1hQGlnYWxpYS5jb20m Z3Q7LCBFbGlvdCBMZWFyICZsdDtsZWFyPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW2Rpc3BhdGNoXSBQcm9wb3NlZCBjaGFydGVyIGZvciBl eHRlbmRlZCBkYXRlIGZvcm1hdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBhbSBsb29raW5nIGZvcndhcmQgdG8gc2VlaW5nIHRoZSBj aGFydGVyIGZvciB0aGlzIFdHIGFkb3B0ZWQsIHNvIHRoYXQgd2UgY2FuIHdvcmsgb24gdGhlIHN1 YnN0YW50aXZlIGlzc3VlcyBpbiB0aGF0IGZvcnVtLiZuYnNwOyBXaGF0IGFyZSB0aGUgbmV4dCBz dGVwcyB0byBhZG9wdCB0aGUgY2hhcnRlcj88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBBcHIgMjAs IDIwMjEgYXQgODoyMSBBTSBFbGlvdCBMZWFyICZsdDs8YSBocmVmPSJtYWlsdG86bGVhckBjaXNj by5jb20iPmxlYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+SnVzdCB0byBmb2xsb3cgdXAgb24gdGhpcywgaW4gY2FzZSB0aGVyZSBp cyBhbnkgcXVlc3Rpb24gb3IgaWYgYW55b25lIGlzIGtlZXBpbmcgc2NvcmUsIG15IHF1ZXN0aW9u IGhhcyBiZWVuIGFuc3dlcmVkIHRvIG15IHNhdGlzZmFjdGlvbiBhbmQgSSBzdXBwb3J0IHRoaXMg d29yayBwcm9jZWVkaW5nLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+RWxpb3Q8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIDE0 IEFwciAyMDIxLCBhdCAxOTo0MiwgRWxpb3QgTGVhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlYXI9 NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sZWFyPTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlNpZ25lZCBQR1AgcGFydDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPkp1c3Qgb25lIHF1ZXN0aW9uOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SXMgaXQgbmVjZXNzYXJ5IGZvciA8Yj5ib3RoPC9i PiB0aGUgSUVURiBhbmQgVEMzOSB0byBzdGFuZGFyZGl6ZSB0aGlzPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5FbGlvdDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMTQgQXByIDIwMjEsIGF0IDE4OjAwLCBCcm9u IEdvbmR3YW5hICZsdDs8YSBocmVmPSJtYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmJyb25nQGZhc3RtYWlsdGVhbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMg d2FzIGRpc2N1c3NlZCBpbiB0aGUgRElTUEFUQ0ggbWVldGluZyBhdCBJRVRGMTEwOiZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTEwLWRpc3Bh dGNoLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21p bnV0ZXMtMTEwLWRpc3BhdGNoLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5UaGUgY29uY2x1c2lvbiBvZiB0aGUgZGlzY3Vzc2lvbiB3YXM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7Zm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPiogS2lyc3R5IChjaGFpcik6IFNvdW5kcyBsaWtlIHRoZXJlJ3Mg Z2VuZXJhbCBhZ3JlZW1lbnQgdGhhdCBhIHdvcmtpbmcgZ3JvdXAgaXM8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPndoYXQncyBuZWVkZWQsIHdlIHdpbGwgdGFrZSBhIGZpbmFsIGRlY2lz aW9uIG9uIHRoZSBsaXN0IGFuZCBqdXN0IGNvbmZpcm0gd2l0aDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+UGF0cmljayBhcyBjby1jaGFpciBiZWZvcmUgb2ZmaWNpYWxseSBkaXNwYXRj aGluZyBhcyBzdWNoLiBUaGUgbGluayB0byB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPmNoYXJ0ZXIgaXMgb24gbGlzdCB0b28sIHBsZWFzZSB0YWtlIGEgbG9vayBhbmQgc2VlIGlm IHlvdSB0aGluayBhIEJvRiBpcyBuZWVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PmFzIHRoZSBuZXh0IHN0ZXAgb3IgYSBXRyBjYW4gYmVnaW4gcmlnaHQgYXdheS48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TbyBNdXJyYXkgKEFEKSwgZG8geW91IHRoaW5rIHdlIGhh dmUgZW5vdWdoIHRvIHJlcXVlc3QgYSB3b3JraW5nIGdyb3VwIGJlIGNoYXJ0ZWQgZnJvbSB0aGUg ZGlzY3Vzc2lvbiBhbmQgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBxdW90ZWQgYmVsb3c/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkJyb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5PbiBGcmks IEZlYiAxOSwgMjAyMSwgYXQgMTU6MjAsIEJyb24gR29uZHdhbmEgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3dvcmQtc3BhY2luZzowcHgiIGlkPSJnbWFpbC1tXzIwNDg3MDkzNjc0OTkxNzkyMjhxdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+SSd2ZSBhc2tlZCB0aGUgY2hhaXJzIGZvciBzcGFjZSBvbiB0aGUgbmV4 dCBkaXNwYXRjaCBhZ2VuZGEgdG8gdGFsayBhYm91dCBkaXNwYXRjaCBmb3I8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1yeXpva3VrZW4tZGF0ZXRpbWUtZXh0ZW5kZWQvIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnl6b2t1a2VuLWRh dGV0aW1lLWV4dGVuZGVkLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5UaGUgYXV0aG9ycyBoYXZlIHRha2VuIG9uIGJvYXJkIHRoZSBpZGVhIHRoYXQgd2Ugc2hvdWxk IGV4dHJhY3QgdGhlICZxdW90O29ic29sZXRlIFJGQzMzMzkmcXVvdDsgYW5kIGVpdGhlciByZW1v dmUgaXQgZW50aXJlbHksIG9yIHNlcGFyYXRlIGl0IGludG8gYSBkb2N1bWVudA0KIHdoaWNoIGRv ZXMgbm90aGluZyBidXQgdXBkYXRlIFJGQzMzMzkgd2l0aCBzdXBwb3J0IGZvciBhIHdpZGVyIHJh bmdlIG9mIHllYXIgdmFsdWVzLiZuYnNwOyBUaGVyZSB3aWxsIGJlIGFuIHVwZGF0ZWQgdmVyc2lv biBvZiB0aGlzIGRyYWZ0IHNvb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+VGhlIGRpc3BhdGNoIGNoYWlycyBhbHNvIGFza2VkIG1lIGZvciBzb21lIHByb3Bvc2VkIGNo YXJ0ZXIgdGV4dCBpZiB3ZSB3ZXJlIHRvIHNwaW4gdXAgYSB3b3JraW5nIGdyb3VwIGZvciB0aGlz IHRvcGljLiZuYnNwOyBIZXJlJ3MgdGhhdCB0ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+QnJvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvIj5TZXJpYWxpc2luZyBFeHRlbmRl ZCBEYXRhIEFib3V0IFRpbWVzIGFuZCBFdmVudHMgKFNFREFURSk8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6TWVubG8iPi0tLS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6TWVubG8iPlJGQzMzMzkgZGVmaW5lcyBhIGZvcm1hdCB0aGF0IGNhbiByZWxpYWJseSBleHBy ZXNzIGFuIGluc3RhbnQgaW4gdGltZSwgZWl0aGVyIGluIFVUQyBvciBpbiBhIGxvY2FsIHRpbWUg YWxvbmcgd2l0aCB0aGUgb2Zmc2V0IGFnYWluc3QgVVRDLCBob3dldmVyIGRhdGV0aW1lIGRhdGEN CiBvZnRlbiBoYXMgYWRkaXRpb25hbCBjb250ZXh0LCBzdWNoIGFzIHRoZSB0aW1lem9uZSBvciBj YWxlbmRhciBzeXN0ZW0gdGhhdCB3YXMgaW4gdXNlIHdoZW4gdGhhdCBpbnN0YW50IHdhcyByZWNv cmRlZC4gUGFydGljdWxhcmx5IHdoZW4gdXNpbmcgdGltZXMgZm9yIGludGVydmFsLCByZWN1cnJl bmNlLCBvciBvZmZzZXQgY2FsY3VsYXRpb25zLCBpdCdzIG5lY2Vzc2FyeSB0byBrbm93IHRoZSBj b250ZXh0IGluIHdoaWNoIHRoZSB0aW1lcG9pbnQNCiBleGlzdHMuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5Ok1lbmxvIj5JdCBpcyB2YWx1YWJsZSB0byBoYXZlIGEgc2VyaWFsaXNhdGlv biBmb3JtYXQgd2hpY2ggcmV0YWlucyB0aGlzIGNvbnRleHQgYW5kIGNhbiByZWxpYWJseSByb3Vu ZC10cmlwIHRoZSBhZGRpdGlvbmFsIGNvbnRleHQgdG8gc3lzdGVtcyB3aGljaCB1bmRlcnN0YW5k IGl0LCB2aWENCiBpbnRlcm1lZGlhdGUgc3lzdGVtcyB3aGljaCBvbmx5IG5lZWQgdG8ga25vdyBh Ym91dCB0aGUgaW5zdGFudCBpbiB0aW1lLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpN ZW5sbyI+VGhlIFRDMzkgd29ya2luZyBncm91cCBhdCBFQ01BIGhhdmUgZGV2ZWxvcGVkIGEgZm9y bWF0IHdoaWNoIGlzIGEgZ29vZCBiYXNpcyBmb3IgdGhpcyB3b3JrLjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTpNZW5sbyI+SXQgaXMgYW50aWNpcGF0ZWQgdGhhdCB0aGlzIGRvY3VtZW50 IHdvdWxkIGJlIGEgY29tcGFuaW9uIHRvIFJGQzMzMzkgcmF0aGVyIHRoYW4gYSByZXBsYWNlbWVu dCwgZW1iZWRkaW5nIGFuIHVuLWFsdGVyZWQgUkZDMzMzOSBpbnN0YW50IGFsb25nIHdpdGggdGhl IGNvbnRleHR1YWwNCiBkYXRhLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpNZW5sbyI+ SXQgaXMgYWxzbyB3aXRoaW4gc2NvcGUgZm9yIHRoaXMgZ3JvdXAgdG8gY29uc2lkZXIgYSBtaW5v ciB1cGRhdGUgdG8gUkZDMzMzOSB0byBhbGxvdyBsYXJnZXIgdGhhbiA0IGRpZ2l0IHNpZ25lZCB5 ZWFycywgdG8gZW5hYmxlIHJlcHJlc2VudGluZyB0aW1lcyBmdXJ0aGVyIGludG8NCiB0aGUgcGFz dCBhbmQgZnV0dXJlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpNZW5sbyI+T25jZSB0 aGlzIHdvcmsgaXMgZG9uZSBpdCBpcyBhbnRpY2lwYXRlZCB0aGF0IHRoaXMgd29ya2luZyBncm91 cCB3aWxsIGJlIHNob3J0LWxpdmVkLCBhbmQgb25jZSB0aGUgb25lIG9yIHR3byBkb2N1bWVudHMg YXJlIHB1Ymxpc2hlZCB0aGUgd29ya2luZyBncm91cCB3aWxsIGNsb3NlDQogZG93bi48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6TWVubG8iPk1pbGVzdG9uZXM6PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvIj4qIEFwcmlsIDIwMjE6IEFkb3B0IGRyYWZ0IGRl c2NyaWJpbmcgYSBzZXJpYWxpc2F0aW9uIGZvcm1hdCBmb3IgZXh0ZW5kZWQgZGF0ZXRpbWVzLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpNZW5sbyI+KiBKdWx5IDIwMjE6IFN1 Ym1pdCB0aGUgc2VyaWFsaXNhdGlvbiBkb2N1bWVudCB0byB0aGUgSUVTRy48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzIwNDg3 MDkzNjc0OTkxNzkyMjhxdC1zaWc1NjYyOTQxNyI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5i c3A7IEJyb24gR29uZHdhbmEsIENFTywgRmFzdG1haWwgUHR5IEx0ZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5Okhl bHZldGljYSI+Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmJyb25nQGZhc3RtYWlsdGVhbS5j b20iIHRhcmdldD0iX2JsYW5rIj5icm9uZ0BmYXN0bWFpbHRlYW0uY29tPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fMjA0ODcwOTM2NzQ5OTE3OTIyOHNpZzU2NjI5NDE3Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPi0tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsgQnJvbiBHb25kd2FuYSwgQ0VPLCBGYXN0bWFp bCBQdHkgTHRkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsmbmJzcDs8YSBocmVmPSJt YWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJyb25nQGZhc3Rt YWlsdGVhbS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCmRpc3BhdGNoIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 ZGlzcGF0Y2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPmRpc3BhdGNoQGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxi cj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Rpc3BhdGNoIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Rpc3BhdGNoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F8A42AE089534C0093E3FE62DA41F64Dericssoncom_-- From nobody Fri Apr 30 14:37:57 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D933A27C3 for ; Fri, 30 Apr 2021 14:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6WaK8MhdQD0 for ; Fri, 30 Apr 2021 14:37:46 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 5FF2D3A27C4 for ; Fri, 30 Apr 2021 14:37:45 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id l17so40072103oil.11 for ; Fri, 30 Apr 2021 14:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w1Q1xCyUlS5YecimIPNpEdvwo4WoaGXjHkYy0ET4Gq8=; b=G+5BD/4+MSxUlOssMP9ekqqDkHdKas3UOPNUHa9qTsD1njDIGILR2CXOKcZRM055pA OLrbqTVKHeKNhfK4UsqC3/PevtsnBCwPCr8fGtmR5rzEINGvPO5Q+wdxV2cC3Q/GxGy3 t7AOwr/zui2SpmsFO/Y9vpqw9XAkygpPVbX6SArALx1pCRHs1W/9sLh90JWaq4SRtNJs m8IqKfHNznC+OJ0vMDnsVD1Og3WuMmio9QgEy99Cy1sMu9XlBRK2M5f5w0KQHdMlAV/b ORzQ4KW8tGDRXoNySTFW4BDxH+4cOEni7UwkzVkPOt5HaUfglfGcK0HNDzQ332UYxbe2 gLLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w1Q1xCyUlS5YecimIPNpEdvwo4WoaGXjHkYy0ET4Gq8=; b=JlQaOcKTohQe0OOP4x2oVGS9mSCUWG2BcE0WuRnivzDYAxub2AyF0+T4QUeXlZ6HbI jUcPLe0k5Lq2j6grbdJ7gTNaQmholsiTSfRwevEMxx1Ljd5cOSDCxRiptV4JylqJ9Fbo RBt3gAKn2/hFUDeNgTzD1M6Y/1/hKms72KpLdEy2lZNU2XP47gMyz5Cm77LtgQbUoZcc Qn64jRSrEU1RPHp0XiDpkDkvVaQaNJz/FiHmKZcYxndQi9eGIzYcpVYQUYehFC4zEYgc E7COGwtr4TJ2pv5RuJtcXB+bMn4h/Tzjghks2dBfgwnG3mCLqv7G3R19vxR0j9Uj7o3z Auqw== X-Gm-Message-State: AOAM533/yxWrhlI9ZVi0rT1jDVqgB+gmldcl7Cg0Pqz4IQxOYAIcKiIi xEvdMaRWrAYQH7Vi0q0/H9b4niDR4YhBWVPyB/RmKR3Mb3WJ2A== X-Google-Smtp-Source: ABdhPJzbixKWZxm7UKJpZ9r8taFjtGVuQHCHeq99EycD1ixd5lv2sZMGeIN4XADlSjaajU5RSPpCWY5CVSPWGbNPsiE= X-Received: by 2002:aca:b9c1:: with SMTP id j184mr5470835oif.134.1619818664336; Fri, 30 Apr 2021 14:37:44 -0700 (PDT) MIME-Version: 1.0 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> In-Reply-To: From: Samuel Erdtman Date: Fri, 30 Apr 2021 23:37:32 +0200 Message-ID: To: Carsten Bormann Cc: art@ietf.org, IETF SecDispatch , DISPATCH , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="00000000000016ddaf05c1376c64" Archived-At: Subject: Re: [dispatch] [art] [Secdispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 21:37:52 -0000 --00000000000016ddaf05c1376c64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carsten, Thank you for sharing your thoughts. I=C2=B4m not sure I understand your point, maybe you could elaborate a bit = (I have some questions). 1. What do you mean with data at rest, data store in database or file? Or is it data that does not change? Sorry I do not get it. 2. What is weird with saying "Represented in JSON"? is it that the RFC7493 I-JSON subset is not all that JSON could be? (to me this is a reasonable limitation that I in practice never have had to go outside) 3. So I totally get that one does not like XMLDigSig, in my opinion not because of the signing procedures but because of the canonicalization process. When I looked at it I gave up and created a hardcoded template. The difference in canonicalization of JSON (RFC7493 I-JSON subset) according to RFC8785 is like night and day compared to XML canonicalization. In your comment it seems like you are of the opinion that this effort will be as tricky as XMLDigSig. do you think so? 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain tex= t" being bad descriptions. Yes what is signed is the RFC8785 transformation of the input data, but the signature are then put into your data keeping the data in its original =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain text" as opposed to= base64-url encoded. I guess enveloped JWS is a more accurate name but =E2=80=9Cclear text=E2=80= =9D or =E2=80=9Cplain text" is easy to understand. Best regards //Samuel On Wed, Apr 28, 2021 at 5:56 PM Carsten Bormann wrote: > Signing data at rest certainly is a use case that is worth addressing. > > =E2=80=9CRepresented in JSON=E2=80=9D is a weird way to say that the data= model that > describes those data at rest is somehow compatible with the JSON data mod= el > (which isn=E2=80=99t really fully defined, but that is a problem that may= not hurt > you). So if you have a deterministic way to transform your data at rest > into the JSON-like data model subset supported by RFC8785 (which is in tu= rn > based on the RFC7493 I-JSON subset), you then can use RFC8785 to generate= a > text string that (using UTF-8=E2=80=99s deterministic encoding) can in tu= rn be used > as a signing input for well-known signature schemes such as JOSE or COSE. > > This is pretty much what XMLDSig set out to do, except that the XML data > model is even less well-defined and generating a deterministic signing > input from that is even more interesting. Small matters of > interoperability :-) > > None of this has anything to do with =E2=80=9Cclear text=E2=80=9D or =E2= =80=9Cplain text", which > is an exceedingly bad label to apply to signing data at rest that are > believed to be convertable to an RFC8785-subset JSON text. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000016ddaf05c1376c64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carsten,

Thank you for sh= aring your thoughts.

I=C2=B4m not sure I under= stand your point, maybe you could elaborate a bit (I have some questions).<= /div>
1. What do you mean with data at rest, data store in database or = file? Or is it data that does not change? Sorry I do not get it.
=
2. What is weird with saying "Represented in JSON"= ? is it that the RFC7493 I-JSON subset is not all that JSON could be? (to m= e this is a reasonable limitation that I in practice never have had to go o= utside)

3. So I totally get that one does not = like XMLDigSig, in my opinion not because of the signing procedures but bec= ause of the canonicalization process. When I looked at it I gave up and cre= ated a hardcoded template. The difference in canonicalization of JSON (RFC7= 493 I-JSON subset) according to RFC8785 is like night and day compared to X= ML canonicalization. In your comment it seems like you are of the opinion t= hat this effort will be as tricky as XMLDigSig. do you think so?
=
4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2= =80=9Cplain text" being bad descriptions. Yes what is signed is the RF= C8785 transformation of the input data, but the signature are then put into= your data keeping the data in its original =E2=80=9Cclear text=E2=80=9D or= =E2=80=9Cplain text" as opposed to base64-url encoded. I guess envelo= ped JWS is a more accurate name but =E2=80=9Cclear text=E2=80=9D or =E2=80= =9Cplain text" is easy to understand.

Best re= gards
//Samuel








<= div class=3D"gmail_quote">
On Wed, Apr= 28, 2021 at 5:56 PM Carsten Bormann <ca= bo@tzi.org> wrote:
Signing data at rest certainly is a use case that is worth addre= ssing.

=E2=80=9CRepresented in JSON=E2=80=9D is a weird way to say that the data m= odel that describes those data at rest is somehow compatible with the JSON = data model (which isn=E2=80=99t really fully defined, but that is a problem= that may not hurt you).=C2=A0 So if you have a deterministic way to transf= orm your data at rest into the JSON-like data model subset supported by RFC= 8785 (which is in turn based on the RFC7493 I-JSON subset), you then can us= e RFC8785 to generate a text string that (using UTF-8=E2=80=99s determinist= ic encoding) can in turn be used as a signing input for well-known signatur= e schemes such as JOSE or COSE.

This is pretty much what XMLDSig set out to do, except that the XML data mo= del is even less well-defined and generating a deterministic signing input = from that is even more interesting.=C2=A0 Small matters of interoperability= :-)

None of this has anything to do with =E2=80=9Cclear text=E2=80=9D or =E2=80= =9Cplain text", which is an exceedingly bad label to apply to signing = data at rest that are believed to be convertable to an RFC8785-subset JSON = text.

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

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000016ddaf05c1376c64-- From nobody Fri Apr 30 16:04:56 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5017D3A2A46; Fri, 30 Apr 2021 16:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xBYZT2i63BK; Fri, 30 Apr 2021 16:04:47 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C7D3A2A5A; Fri, 30 Apr 2021 16:04:46 -0700 (PDT) Received: from smtpclient.apple (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FX7HH5SCczyTV; Sat, 1 May 2021 01:04:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Carsten Bormann In-Reply-To: Date: Sat, 1 May 2021 01:04:43 +0200 Cc: art@ietf.org, IETF SecDispatch , DISPATCH , "RFC ISE (Adrian Farrel)" Content-Transfer-Encoding: quoted-printable Message-Id: <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> To: Samuel Erdtman X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [dispatch] [art] [Secdispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 23:04:51 -0000 Hi Samuel, > 1. What do you mean with data at rest, data store in database or file? The point is that you are not signing the data being transferred, but a = local copy of some (e.g., freshly decoded) data (i.e., at the data model = level) which is then processed a little (potentially taking out all = signatures) and then is run through a rather complicated engine to = produce a signing input that is a deterministic function of the decoded = and processed data. There are easier ways to get a signing input from JSON-like data at = rest. For a (quite workable) strawman: How about doing a CBOR encoding using = deterministic encoding rules? > Or is it data that does not change? Sorry I do not get it. >=20 > 2. What is weird with saying "Represented in JSON=E2=80=9D? Your scheme does NOT require (or benefit in any way from) representing = the data in JSON. The data could be transferred in YAML (or CBOR for that matter): as long = as your local copy of the decoded data (after the little processing) = sticks inside the confines of the I-JSON data model, you can use your = scheme for signing. > is it that the RFC7493 I-JSON subset is not all that JSON could be? = (to me this is a reasonable limitation that I in practice never have had = to go outside) Well, that has been debated to death, and it is clear that nobody likes = I-JSON (*), but it is the de-facto boundary within which the actually = more capable JSON format needs to be used these days. (If you need more flexibility, you know where to find CBOR.) > 3. So I totally get that one does not like XMLDigSig, in my opinion = not because of the signing procedures but because of the = canonicalization process. When I looked at it I gave up and created a = hardcoded template. The difference in canonicalization of JSON (RFC7493 = I-JSON subset) according to RFC8785 is like night and day compared to = XML canonicalization. In your comment it seems like you are of the = opinion that this effort will be as tricky as XMLDigSig. do you think = so? Indeed, the RFC 8785 encoding is (ignoring potential problems on the = numeric side) simpler than canonicalized XML, even with its weird = regression to UTF16-land. Much of the actual problems of XMLDSig weren=E2=80=99t in the = canonicalization, but in the confusion of how the data at rest was to be = processed for signing, e.g., what part of the data at rest was = contributing to the signing input and what the signature on that part = then actually meant. JWS is probably flexible enough that a carefully = constructed application can get all this right, but we are talking about = non-trivial specifications needed beyond the boring part of generating = the byte-string signing input. > 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain = text" being bad descriptions. Yes what is signed is the RFC8785 = transformation of the input data, but the signature are then put into = your data keeping the data in its original =E2=80=9Cclear text=E2=80=9D = or =E2=80=9Cplain text" as opposed to base64-url encoded. I guess = enveloped JWS is a more accurate name but =E2=80=9Cclear text=E2=80=9D = or =E2=80=9Cplain text" is easy to understand. Well, I understand that the naming you chose is a good strategy for = selling the scheme. It is, however, not describing what is actually going on, and I try to = minimize the use of misleading terminology. Gr=C3=BC=C3=9Fe, Carsten (*) Over at the JSON mailing list, there has been some fresh discussion = just this week about how to get around some of the implementation = limitations, or JSON=E2=80=99s (deliberate!) lack of extensibility, or = both. Archived-At: = = and the thread behind that. From nobody Fri Apr 30 22:10:18 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CAC3A34FE; Fri, 30 Apr 2021 22:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 VWlxTTEL-Erj; Fri, 30 Apr 2021 22:09:55 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 ACE723A34F6; Fri, 30 Apr 2021 22:09:54 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id a4so86153wrr.2; Fri, 30 Apr 2021 22:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=u8qIHe5b4hf0eWlCnhn0XaplDlT7QB4WqvllYh2vxb8=; b=Fp8hljepo4sks3fFVW0zZOC3wnSIXMo3BkxPnwl7nMLkFVwTAIw53SooS7D2ddeVoI JaKMZezUcu28YhvHMPOG0CIn5L52tjGon5V6TZPcdnz75hY9wo4ec4NhvLCONnq10/0f N+LDdK1pGZuiQinpt0GQMkChuZvh6GoO3HVDJFo8XFBJAhOqlAK6LuPX23DIdBnfi+1Q DxDjdyLUHuvZxK+4dFP/CgWNKn0bRzg0DMVfCo3pSutJDmHKAMdweWLicqmw6lF2tbhm V29EevScth3e451Lff9PIC7Lj9Q2wHZjyiTEegjQdLQER8rNt8z24pHeigGU4wXLMJae vkpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=u8qIHe5b4hf0eWlCnhn0XaplDlT7QB4WqvllYh2vxb8=; b=XRLMIsAncl2n6X0A5XNKMhEhWCQiBiogZK/YLm7EYDlO3ry0gnmU0KkgEYPQKgh6S6 v/cha7TZzVnmFuLfvrjjtLwy7W0ErWwb/eKCBtRSpML+jVJuyyh7G9y+GYR1etd6seHc GpRhxljBpzwxXPkdt4cwCBq1te+Kvj8IDS1bNqqCY1Npannfvuj7UdZaGL0MwMq+4sNe +A4FDhrzZY+QKRUuveG/Iv4kkjujW++YVSSBjU0uHkzd2fbo5E1/2QdLJJXmStgyHhEu NhOqy97Y45crcO2F/SeiQT1cbxl0wmkptIYvvrSlBA4plmpTJ4T3ukJxrpZcwJJx59cX h5zA== X-Gm-Message-State: AOAM531MR/ORc9lpkbSCJDwXLPV0Vz7qgMbBZOf3hHxY6bCbO7Yks0YL XTRXdr7SWmppBW1ecIwje70= X-Google-Smtp-Source: ABdhPJzG2Vd42Waskgx8kWUJYOI4N8KXoR7jnjvsu4mE1+ikwFDArIryXdIfrxdWSDnuL4Jz3J1LFg== X-Received: by 2002:adf:facf:: with SMTP id a15mr12132964wrs.53.1619845791872; Fri, 30 Apr 2021 22:09:51 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id y125sm4560376wmy.34.2021.04.30.22.09.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Apr 2021 22:09:50 -0700 (PDT) To: Carsten Bormann , Samuel Erdtman Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> From: Anders Rundgren Message-ID: <94ced44c-7a45-0870-e2bd-fb4909324a61@gmail.com> Date: Sat, 1 May 2021 07:09:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] [art] [Secdispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 05:10:00 -0000 On 2021-05-01 1:04, Carsten Bormann wrote: > Your scheme does NOT require (or benefit in any way from) representing the data in JSON. I don't have an answer or solution for people who firmly believe that JSON is (more or less) useless. Stepping-up the game a bit :) We have had 25y+ (!) of non-standard, security-broken, and user-hostile on-line payment-systems. AFAIK, the following document is currently the ONLY specification that addresses this obvious deficiency: https://fido-web-pay.github.io/specification/#operation Browsers, FIDO, JavaScript, JSON, JWS, JWE, RFC 8785, and JWS/CT are the corner stones of this proposal. Yes, there is even a spoon with CBOR/COSE there. Regarding RFC 8785, it works as claimed for applications adhering to two fairly reasonable requirements: - Sticking to I-JSON where the SHOULDs are interpreted as MUSTs. - Using parser schemes that do not mess up data embedded in JSON strings (like converting "2021-05-01T10:00:00Z" to "2021-05-01T09:00:00+01:00"). In all "modesty", Anders > Hi Samuel, > >> 1. What do you mean with data at rest, data store in database or file? > > The point is that you are not signing the data being transferred, but a local copy of some (e.g., freshly decoded) data (i.e., at the data model level) which is then processed a little (potentially taking out all signatures) and then is run through a rather complicated engine to produce a signing input that is a deterministic function of the decoded and processed data. > > There are easier ways to get a signing input from JSON-like data at rest. > For a (quite workable) strawman: How about doing a CBOR encoding using deterministic encoding rules? > >> Or is it data that does not change? Sorry I do not get it. >> >> 2. What is weird with saying "Represented in JSON”? > > Your scheme does NOT require (or benefit in any way from) representing the data in JSON. > The data could be transferred in YAML (or CBOR for that matter): as long as your local copy of the decoded data (after the little processing) sticks inside the confines of the I-JSON data model, you can use your scheme for signing. > >> is it that the RFC7493 I-JSON subset is not all that JSON could be? (to me this is a reasonable limitation that I in practice never have had to go outside) > > Well, that has been debated to death, and it is clear that nobody likes I-JSON (*), but it is the de-facto boundary within which the actually more capable JSON format needs to be used these days. > (If you need more flexibility, you know where to find CBOR.) > >> 3. So I totally get that one does not like XMLDigSig, in my opinion not because of the signing procedures but because of the canonicalization process. When I looked at it I gave up and created a hardcoded template. The difference in canonicalization of JSON (RFC7493 I-JSON subset) according to RFC8785 is like night and day compared to XML canonicalization. In your comment it seems like you are of the opinion that this effort will be as tricky as XMLDigSig. do you think so? > > Indeed, the RFC 8785 encoding is (ignoring potential problems on the numeric side) simpler than canonicalized XML, even with its weird regression to UTF16-land. > > Much of the actual problems of XMLDSig weren’t in the canonicalization, but in the confusion of how the data at rest was to be processed for signing, e.g., what part of the data at rest was contributing to the signing input and what the signature on that part then actually meant. JWS is probably flexible enough that a carefully constructed application can get all this right, but we are talking about non-trivial specifications needed beyond the boring part of generating the byte-string signing input. > >> 4. Not sure I agree with “clear text” or “plain text" being bad descriptions. Yes what is signed is the RFC8785 transformation of the input data, but the signature are then put into your data keeping the data in its original “clear text” or “plain text" as opposed to base64-url encoded. I guess enveloped JWS is a more accurate name but “clear text” or “plain text" is easy to understand. > > Well, I understand that the naming you chose is a good strategy for selling the scheme. > It is, however, not describing what is actually going on, and I try to minimize the use of misleading terminology. > > Grüße, Carsten > > (*) Over at the JSON mailing list, there has been some fresh discussion just this week about how to get around some of the implementation limitations, or JSON’s (deliberate!) lack of extensibility, or both. Archived-At: and the thread behind that. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >