From nobody Tue Sep  5 16:27:38 2017
Return-Path: <fluffy@iii.ca>
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 F3E8C132198 for <dispatch@ietfa.amsl.com>; Tue,  5 Sep 2017 16:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 Q0D_aHGMMul0 for <dispatch@ietfa.amsl.com>; Tue,  5 Sep 2017 16:27:35 -0700 (PDT)
Received: from smtp72.iad3a.emailsrvr.com (smtp72.iad3a.emailsrvr.com [173.203.187.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0940E132199 for <dispatch@ietf.org>; Tue,  5 Sep 2017 16:27:34 -0700 (PDT)
Received: from smtp34.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 36DAE24C47; Tue,  5 Sep 2017 19:27:29 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E5FDA24C05;  Tue,  5 Sep 2017 19:27:28 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 05 Sep 2017 19:27:29 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <4DC6097A-155C-4EC4-81F4-96333DCC7AB7@iii.ca>
Date: Tue, 5 Sep 2017 17:27:27 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF75C9E5-B55E-4E73-A2F0-FFF0790AB247@iii.ca>
References: <4DC6097A-155C-4EC4-81F4-96333DCC7AB7@iii.ca>
To: DISPATCH <dispatch@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/LcXO36apgxyz9cHd_gc3E4Nrk4A>
Subject: Re: [dispatch] Adoption of Work on ECMAScript Media Types Updates?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Sep 2017 23:27:37 -0000

The chairs did not receive any objections on or off list and will work =
with ADs on next steps.


> On Aug 21, 2017, at 12:21 PM, Cullen Jennings <fluffy@iii.ca> wrote:
>=20
>=20
> If anyone has significant objections to the WG adopting=20
>=20
> https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs
>=20
> as a working document, please let us know by end of the day Sept 4.=20
>=20
> After that we will work with ADs to determine next steps.=20
>=20
> Thanks,=20
>=20
> Cullen <co-chair>
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From nobody Mon Sep 11 17:28:40 2017
Return-Path: <martin.thomson@gmail.com>
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 C2DE4132EBF for <dispatch@ietfa.amsl.com>; Mon, 11 Sep 2017 17:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 ZDP1K5OyjEHM for <dispatch@ietfa.amsl.com>; Mon, 11 Sep 2017 17:28:36 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 B9D55129C41 for <dispatch@ietf.org>; Mon, 11 Sep 2017 17:28:36 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id j141so37137383ioj.4 for <dispatch@ietf.org>; Mon, 11 Sep 2017 17:28:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0rIzntf3nTtFZVrCXlZmDUijVFO5ME0MleVpzgGfpdo=; b=TE52rm77wbFgb1fTgkxoiBuVUu1s9sj1kZaqZRso28zkGSuQ8zi8cBasW5pE89qy+u /ZninRT2aQrIMsvdUbFp3DSDI+9Vl4phkSSd9K9brVL81aPN589R5NVASB3hYdYPPsrb CTVWGnsSAYbecDMJe4P7n6otcdLshq/zkmy3tVox79vEIkJyCn6KFeaSyXgrwz4iJ5lY Mw2xkS9dGuuSg3d6rhWvqGHPmWS1Nk/jUuP41feFTd0UzmUjcNxakxjkshBif4psm5ol 2KlKQWdoo5J8kEr+sty8eoKcC8XbCmmcFU55L/PQjyoGyDsrz9ZMzht2dnKUiFjpbg7u d/pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0rIzntf3nTtFZVrCXlZmDUijVFO5ME0MleVpzgGfpdo=; b=H03U9SKigAjVJ/rYhL2EWaQ5CF6a05LbMwaqc+5+/JvMScio03ZMm+9YZ1qNGXpIxe md9ScYglN/oB3GFq5YC8LdNKnZ3VZXiU8jq5f2Ijw7jd2SvpsMwGilvFveLS9oR3M0Ov wjcOWlX/uN4uxL5suLIc708df/u73xQ+NelanD3TODTRv/ScbGZdVPSfmuRCCl35Ej1W wnfbJ5H8wWt/cBejPj6BHW9Rlks/pveaIzXCOrlpUadurgL2vHuKvnBbboy0QEPF5xgx i7KMk8htXaVjtHvMPpKJMY2wycwFSBC8D07pBnuGsonBhKSyQhVnczRxJY/DeUSduIFQ uHCw==
X-Gm-Message-State: AHPjjUjBhIQH90xZji1/CyJxKG/YXmI0vtiyUeLpeTXi6HFTiGllj1+7 MtLb8pKvqXkyn16E5DvZQP61evWrOCmk
X-Google-Smtp-Source: AOwi7QB1DJV35/GfPppfuwcBjORvJzeFKqtZ8ZfGeWnr2FIzw4M5R3GJ6i3BnTQoiiB+exsNxBoeIu5uwQjwrX5qJu0=
X-Received: by 10.202.170.204 with SMTP id t195mr252232oie.277.1505176116007;  Mon, 11 Sep 2017 17:28:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.14.77 with HTTP; Mon, 11 Sep 2017 17:28:35 -0700 (PDT)
In-Reply-To: <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie>
References: <20170810160035.9804.qmail@ary.lan> <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> <alpine.OSX.2.21.1708101427390.37126@ary.qy> <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 12 Sep 2017 10:28:35 +1000
Message-ID: <CABkgnnWhbW9DDfEswKTQ-+_BRewnw2RGYWOKtVac=zMCTmqODw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: John R Levine <johnl@taugh.com>, Dispatch WG <dispatch@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/0ZmU7MmN_ADb_pseJnPfjkyFjGQ>
Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 00:28:39 -0000

On Fri, Aug 11, 2017 at 5:40 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>> CORS?
>
> Yes. The mention of that in the draft we're discussing is
> a bit of a puzzle to me. Hopefully you didn't read some
> other draft:-)

Let me try to clarify, though I might easily do the opposite.

tl;dr: I think that the draft doesn't need to concern itself with CORS.

CORS *is* relevant in the space of things that this is touching.  One
specific (and useful) outcome of this work is that it allows web
applications to make DNS queries.  That naturally raises the CORS
question.  However, the answer is not any different to any other thing
that we might put on HTTP(S).  The server needs to adopt a policy that
ensures that the data that it provides is not made available to those
that shouldn't have it, and that any actions it takes are properly
safeguarded.  This is still not extraordinary in any way.

The draft in question uses GET.  That means that web content will be
able to make queries without any special controls, but it won't be
able to read the response.  The DNS server can block the request from
certain network locations, but it has to specifically look for an
Origin header field.  Again, this isn't particularly special, though
there are some denial of service considerations we might add to a
draft for this case.

The draft also uses POST, which triggers CORS preflights.  These
requests check that the server is OK with receiving the POST before
sending the actual data.  Here, the default is to deny these requests.
A positive signal from the server is needed before the real request is
made.  So only servers that explicitly enable CORS will receive POST
requests from browsers.

Why is this important?  Well, the identity of your private DNS server
is not usually that private (at least not in a real cryptographic
sense).  But the content of certain responses might be.  The server
might provide responses that differ from the responses you get from
other DNS servers.  Operators of DNS servers do not necessarily want
that information out there on the web.  This might include information
about what services are active on the network, network topology and so
forth.

We might get into a whole lot more trouble if we were to - say -
provide an API that allowed web sites to make DNS queries using the
system resolver.  I keep hearing that suggested and I think that this
draft offers a much better alternative - it allows us to lean on a lot
of pre-existing work around cross-origin authentication and ensures
that DNS servers are given at least a semblance of control over who
can ask them for stuff.


From nobody Tue Sep 12 08:03:44 2017
Return-Path: <pmcmanus@mozilla.com>
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 233511329AD for <dispatch@ietfa.amsl.com>; Tue, 12 Sep 2017 08:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level: 
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nApkIXRewTzZ for <dispatch@ietfa.amsl.com>; Tue, 12 Sep 2017 08:03:41 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2791326F6 for <dispatch@ietf.org>; Tue, 12 Sep 2017 08:03:41 -0700 (PDT)
Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id 82D6D3A01B for <dispatch@ietf.org>; Tue, 12 Sep 2017 11:03:37 -0400 (EDT)
Received: by mail-lf0-f42.google.com with SMTP id c80so27184138lfh.0 for <dispatch@ietf.org>; Tue, 12 Sep 2017 08:03:37 -0700 (PDT)
X-Gm-Message-State: AHPjjUg9yCmuvqLtzzE0zOh8ZBOKGPtuXJLbPZ4KGm4cv0jvbBPLY8Nq oBwq+F1lIBAhjLoSpc2F8urHi4XSOw==
X-Google-Smtp-Source: AOwi7QD7meSPwVkoPIrNRA9AksfSoBMzrqbPS/EhMaKuWORbfqiCVj6IF2ZUpkOTO65QsapvyPaf9UgzbYugiE/FhG0=
X-Received: by 10.46.95.203 with SMTP id x72mr188931lje.40.1505228616152; Tue, 12 Sep 2017 08:03:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.92.200 with HTTP; Tue, 12 Sep 2017 08:03:34 -0700 (PDT)
In-Reply-To: <CABkgnnWhbW9DDfEswKTQ-+_BRewnw2RGYWOKtVac=zMCTmqODw@mail.gmail.com>
References: <20170810160035.9804.qmail@ary.lan> <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> <alpine.OSX.2.21.1708101427390.37126@ary.qy> <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie> <CABkgnnWhbW9DDfEswKTQ-+_BRewnw2RGYWOKtVac=zMCTmqODw@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 12 Sep 2017 11:03:34 -0400
X-Gmail-Original-Message-ID: <CAOdDvNrMGtfUePLNiYC_Ksd1oY_Yhiv-44xs5kO7h1Z8fUD+Yw@mail.gmail.com>
Message-ID: <CAOdDvNrMGtfUePLNiYC_Ksd1oY_Yhiv-44xs5kO7h1Z8fUD+Yw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Dispatch WG <dispatch@ietf.org>, John R Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary="94eb2c0d97cef8bca00558ff5835"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/sqlx8q4n7qRFe7XwxCwgrnIxxos>
Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 15:03:43 -0000

--94eb2c0d97cef8bca00558ff5835
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 11, 2017 at 8:28 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

>
>
> We might get into a whole lot more trouble if we were to - say -
> provide an API that allowed web sites to make DNS queries using the
> system resolver.  I keep hearing that suggested and I think that this
> draft offers a much better alternative - it allows us to lean on a lot
> of pre-existing work around cross-origin authentication and ensures
> that DNS servers are given at least a semblance of control over who
> can ask them for stuff.
>

yes, just to underline this it is a goal of this work to make resolution
available to the usual origin web security model (which martin nicely
describes).. we shouldn't have to say much about it as the point is to use
it unmodified (and without surprises).

--94eb2c0d97cef8bca00558ff5835
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Sep 11, 2017 at 8:28 PM, Martin Thomson <span dir=3D"ltr">&lt;<=
a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
We might get into a whole lot more trouble if we were to - say -<br>
provide an API that allowed web sites to make DNS queries using the<br>
system resolver.=C2=A0 I keep hearing that suggested and I think that this<=
br>
draft offers a much better alternative - it allows us to lean on a lot<br>
of pre-existing work around cross-origin authentication and ensures<br>
that DNS servers are given at least a semblance of control over who<br>
can ask them for stuff.<br></blockquote><div><br></div><div>yes, just to un=
derline this it is a goal of this work to make resolution available to the =
usual origin web security model (which martin nicely describes).. we should=
n&#39;t have to say much about it as the point is to use it unmodified (and=
 without surprises).<br></div><div>=C2=A0<br></div></div></div></div>

--94eb2c0d97cef8bca00558ff5835--


From nobody Thu Sep 28 01:43:47 2017
Return-Path: <rsto@fastmailteam.com>
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 D87AC13455A for <dispatch@ietfa.amsl.com>; Thu, 28 Sep 2017 01:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlV6mBeSytdH for <dispatch@ietfa.amsl.com>; Thu, 28 Sep 2017 01:43:40 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F05F13457E for <dispatch@ietf.org>; Thu, 28 Sep 2017 01:43:40 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9647120778; Thu, 28 Sep 2017 04:43:39 -0400 (EDT)
Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Thu, 28 Sep 2017 04:43:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=dQR5ToTSUw5zwpa76SG3wrJbr42xV Os+L92UcPZXKTw=; b=IKxLEQZqdmUldTnq95PGanHvIl8AWWsgflFIzFDnFki9w d/kg9csesBfZyYFwxCcd9fMMMQhj8yzOgWKIoPYjzavuHKEp1u0liuEz4C+tc0Cc 8q5Gu1OpXeAoWsS6OiON1scaMsQzsv6APW24dCruHFE3SYOFdUUOwoWSolOiikXq zLgTtnii4LrZ132Ps8Kt/yEnQ5kjCclzk8LPJMap791kB74VLAkocuVxB55xwASx UA+tt6bSDSj7YC/4hc6p6J0cJv9/Ibe8R0nOhDSaPzcin/tYE3cFvQ7VTIfKwIid UMSOi7Q96e8CbwX7FzP1TVa1T/9uZlW5zpPyzckRg==
X-ME-Sender: <xms:O7bMWeaggTB9W-OArqnawo0tG8c-zDcR7RlLMBr6zYvRaecRR7lxqQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6BBD46269A; Thu, 28 Sep 2017 04:43:39 -0400 (EDT)
Message-Id: <1506588219.485384.1120927832.1112E2F6@webmail.messagingengine.com>
From: Robert Stepanek <rsto@fastmailteam.com>
To: dispatch@ietf.org
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, Neil Jenkins <neilj@fastmailteam.com>, Bron Gondwana <brong@fastmailteam.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cb49228
Date: Thu, 28 Sep 2017 10:43:39 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/BJc8lFl4J-GThT4OgaojQ4yLhIE>
Subject: [dispatch] Feedback requested: draft-jenkins-jscalendar
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Sep 2017 08:43:45 -0000

Hi,

over the last year we have been working on JSCalendar, a JSON-based
representation of calendar data as an alternative to iCalendar
(RFC5545).  We already got extensive feedback from the members of
CalConnect  and individual contributors and we'd very much like to get
the discussion started on our proposal at IETF.

There's an increasing amount of proprietary calendar data formats in the
industry, most of them JSON-based. We believe that a new standardised
calendar data representation that meets the requirements of these
applications would help to reduce interoperability issues while
overcoming iCalendar pitfalls and ambiguities.

The current draft version is located at
https://datatracker.ietf.org/doc/draft-jenkins-jscalendar/

Do you have any feedback on this? What would make you use  the new
format, what is it currently missing?

Thanks for your thoughts,
Robert

P.S.: This message got cross-posted to the CALSIFY workgroup.


From nobody Thu Sep 28 18:58:26 2017
Return-Path: <worley@alum.mit.edu>
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 A4DC5134A18 for <dispatch@ietfa.amsl.com>; Thu, 28 Sep 2017 18:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFQfuNzfbOrd for <dispatch@ietfa.amsl.com>; Thu, 28 Sep 2017 18:58:23 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 001F9134A15 for <dispatch@ietf.org>; Thu, 28 Sep 2017 18:58:22 -0700 (PDT)
Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id xkY6ds7ddzQG8xkZKdfy4I; Fri, 29 Sep 2017 01:58:22 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-14v.sys.comcast.net with SMTP id xkZId4lCGCzrXxkZIdQ8oI; Fri, 29 Sep 2017 01:58:21 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v8T1wKLi023735; Thu, 28 Sep 2017 21:58:20 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8T1wJf0023732; Thu, 28 Sep 2017 21:58:19 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Robert Stepanek <rsto@fastmailteam.com>
Cc: dispatch@ietf.org, neilj@fastmailteam.com, brong@fastmailteam.com
In-Reply-To: <1506588219.485384.1120927832.1112E2F6@webmail.messagingengine.com> (rsto@fastmailteam.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Thu, 28 Sep 2017 21:58:19 -0400
Message-ID: <87h8vm8dvo.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfOJWG/6QXNxm5GioS1fQBSCTZk096+Tb9x2NTKwykN88uDHrHnxzg56/npxTrOB28FqfTef6cWhfTHlgw4rrADi9HVNsI+KLiS2nN6yTLP4zRkcj0+2/ epnvF/gSUtUSP1v/KCDeunhr0xIQDLio8liVLh2nfMtoW8pJxMqQ9zWKkabs8dJnZdnI39LBXO8uX+/rTTqiEffEX8V6pBNpTiCPa0pee7pOHLMCAwsARNyc yV+vviDP+p9wLhds2nOrZNmNbyeTiuqqTmhQzbHsgLY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/vRHpxLZ4xiJi2luhu-65cUcYMw0>
Subject: Re: [dispatch] Feedback requested: draft-jenkins-jscalendar
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Sep 2017 01:58:25 -0000

Robert Stepanek <rsto@fastmailteam.com> writes:
> Do you have any feedback on this? What would make you use  the new
> format, what is it currently missing?

Given that any practical implementation has to interoperate with iCal,
the barrier to entry is high.  To what degree is this addressing actual
failures of iCal (e.g., where iCal is ambiguous) and to what degree is
it just *simpler* for the implementor?  (Coming from the world of SIP,
I've learned that things that are nightmarish for implementors are often
criticial to real-world use of the protocol) Ease of implementation is
nice, but given the need to interoperate with iCal for many years, it
has limited value.  Also, to what degree does the simplicity of
JSCalendar simply push work back into the interface between the
calendaring system and the JSCalendar interface?

I suspect that in practice, semantic upward-compatibility from iCal will
be important.  You mention in section 1 item 3, "a conversion between
the data formats is not guaranteed to be completed without losing
semantic meaning".  What exactly are the incompatibilities?

Dale


From nobody Fri Sep 29 06:04:24 2017
Return-Path: <session-request@ietf.org>
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 62E211321A4; Fri, 29 Sep 2017 06:04:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool <session-request@ietf.org>
To: <session-request@ietf.org>
Cc: alexey.melnikov@isode.com, ben@nostrum.com, dispatch@ietf.org, dispatch-chairs@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150669026236.14161.17789057385168294449.idtracker@ietfa.amsl.com>
Date: Fri, 29 Sep 2017 06:04:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/EYSjCrcKzH3TpFm4DmMLtorabLE>
Subject: [dispatch] dispatch - New Meeting Session Request for IETF 100
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Sep 2017 13:04:22 -0000

A new meeting session request has just been submitted by Alexey Melnikov, a ART Area Director.


---------------------------------------------------------
Working Group Name: Dispatch
Area Name: Applications and Real-Time Area
Session Requester: Alexey Melnikov

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: dmarc uta jmap xrblock webpush stir sipcore rtcweb rmcat payload netvc mmusic insipid ecrit avtcore bfcpbis clue core dcrup doh extra
 Second Priority: tram tsvwg tsvarea opsarea lmap



People who must be present:
  Alexey Melnikov
  Mary Barnes
  Adam Roach
  Ben Campbell
  Cullen Jennings
  Murray Kucherawy

Resources Requested:

Special Requests:
  Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs.
---------------------------------------------------------