From nobody Thu Jan 11 16:30:31 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EACD126C2F for ; Thu, 11 Jan 2018 16:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=RHI9i0R8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZKR3EAGZ 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 J_uj1Vl-Q61S for ; Thu, 11 Jan 2018 16:30:27 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29926126D85 for ; Thu, 11 Jan 2018 16:30:27 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 86FFC208B8; Thu, 11 Jan 2018 19:30:26 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 11 Jan 2018 19:30:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jbimMg kIX47pUVU71vPUDzCP74WUPgT/Go2kbqf1CfQ=; b=RHI9i0R8QTbC+TM4zJXks5 PSkYMJwNpz+YhhdasImznXIM9Wki0K1TTNZqRIPasVHJ0nVUXyKFPsKLmXl90f5i f8uARezXPDIrTW0OnjmGXJUQUniSKxhDk0BitYnO1RzZtFLHJdPSo3pyeGR/SPbn lMQaB5O28XMFbCT2p06fAfbEb5jZ254ojD7S+OAUaUmVHrRwUNBlalycpBcKvZ3Z jpyrMwAR9Pc5nwWjtfnB56wdMZr4O3jfOssBt3wglnBIfLNg57pkAYXjfMD4gxv4 BPFW13bOmef6/hZtvKG9QcifgGQH0pBXNuAt9PdZjCVWjGxOozUmH4qL9HvzMisw == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jbimMg kIX47pUVU71vPUDzCP74WUPgT/Go2kbqf1CfQ=; b=ZKR3EAGZoUp6ps8AZEb7Kw +ybP018e+VQF7ivZN7Na6RjljIrw+5PlDYYKq2yTkTJcEZkzt9d1oqTa+uW8TMGu c8VSvAVpwG0eJHRDi5WEkDVSwqjWzSX5WMU3d7UAsvYF9H74cuCaHvbm+hHxqQly 0B42P1LWafnSaP+uA9qm7i2xAQ/wfFnxQh8skT3n0a4eIr+AUJ+EabATwJ/ss9WO qye/ae0vz3AoDu56UhdR2MVNm27AA9xNzLV560z66gqbwmPpKOYs7OOuUdsig2YC mJ8CEtQsa11tu+CD5wHdh+9ulJXQ80QSgbdw+A98oWXz0iArhsPTKG0CdkH4fjxw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 41653E2495; Thu, 11 Jan 2018 19:30:26 -0500 (EST) Message-Id: <1515717026.2492419.1232591368.630FE6BF@webmail.messagingengine.com> From: Neil Jenkins To: Alexey Melnikov Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151571702624924190" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6f0a5656 Date: Fri, 12 Jan 2018 11:30:26 +1100 In-Reply-To: References: <1513222733.562048.1204501864.2B4A2737@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] JMAP Core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 00:30:29 -0000 This is a multi-part message in MIME format. --_----------=_151571702624924190 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 22 Dec 2017, at 10:43 PM, Alexey Melnikov wrote: > I think value 1 is rather limiting and will prevent the protocol from > being useful, because clients might have to potentially have multiple > code paths to cope with maxCallsInRequest == 1 and more capable > servers. Based on the feedback in #86[1], I went with a minimum value of 32. Based on our experience using the protocol, 16 would be fine for normal usage, if you think 32 is too high? > *#89*[2]* Do we need a registry of error types? * > > Yes, I think we need to have a registry. I find IANA registries to be > useful for implementing things and finding out what was already > registered. Hmm, the feedback I've had off-list is this is probably not necessary. I have gone through RFC 5530[3] to make sure any relevant errors are covered in the spec, and the consensus seemed to be that entirely new classes of error were unlikely to appear. It greatly helps client authors to know the complete set of errors that may be returned to ensure everything is handled in an appropriate manner; this should make that easier. >> How do I go about creating a registry presuming we decide we do >> need one?> I can suggest some text on this. I think the main thing to decide > first is the registration policy. Do we want some kind of expert > review for them? If we do decide to create a registry, I think some kind of expert review is reasonable, especially if it's meant to be a new generally applicable error that any method could return. Neil. Links: 1. https://github.com/jmapio/jmap/issues/86 2. https://github.com/jmapio/jmap/issues/89 3. https://tools.ietf.org/html/rfc5530 --_----------=_151571702624924190 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 22 Dec 2017, at 10:43 PM, Alexey Melnikov wrote:
I think value 1 is rather limiting and will prevent the protocol from being useful, because clients might have to potentially have multiple code paths to cope with maxCallsInRequest == 1 and more capable servers.

Based on the feedback in #86, I went with a minimum value of 32. Based on our experience using the protocol, 16 would be fine for normal usage, if you think 32 is too high?

#89 Do we need a registry of error types?

Yes, I think we need to have a registry. I find IANA registries to be useful for implementing things and finding out what was already registered.

Hmm, the feedback I've had off-list is this is probably not necessary. I have gone through RFC 5530 to make sure any relevant errors are covered in the spec, and the consensus seemed to be that entirely new classes of error were unlikely to appear. It greatly helps client authors to know the complete set of errors that may be returned to ensure everything is handled in an appropriate manner; this should make that easier.

How do I go about creating a registry presuming we decide we do need one?
I can suggest some text on this. I think the main thing to decide first is the registration policy. Do we want some kind of expert review for them?

If we do decide to create a registry, I think some kind of expert review is reasonable, especially if it's meant to be a new generally applicable error that any method could return.

Neil.
--_----------=_151571702624924190-- From nobody Thu Jan 11 17:30:13 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0193F1270AB for ; Thu, 11 Jan 2018 17:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 f5Uy-9QgHj5V for ; Thu, 11 Jan 2018 17:30:10 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 21E6E126BF0 for ; Thu, 11 Jan 2018 17:30:10 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0C1NLZM039813; Fri, 12 Jan 2018 01:30:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2017-10-26; bh=XzaLT3xXrFIo99wVM7NIoQuSoPgtnqPnscNQcdgHdME=; b=U/Cvmu6Xa+CNpmgn05CTfu84oT8OBvWnRqlBQdLZhexohM2G/pj31FiqTmFHmSXL84af lnMCwP2MiwgkCZB42ss5zQvpRDDA/x33scZ4meWeUFpD23twlcToSU8vGRzixKYpC2HZ L3aMYvDkPrmwHcfJKoSgEvm2Q8Bv/QPDJ2xzIE0PQAbIJlsdrnB3HFlmmwi09tHhg17/ iOw7u4WWF6tKb9cVHoPYC00flm6j5H91RdG2zOZ44c2tjwhgp1LvnHw3XGfeGt/NqYHs MJ/O5oEQ87szanKaZ/0vw4ZYK01UhQdMDjR88IASLH1nPxjfBTpEwr/1jpp4emsvd5TF KQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2fej6p85hk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Jan 2018 01:30:06 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w0C1P5iu011600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Jan 2018 01:25:05 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0C1P47i005418; Fri, 12 Jan 2018 01:25:05 GMT Received: from [10.159.237.236] (/10.159.237.236) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Jan 2018 17:25:04 -0800 From: "Chris Newman" To: "Neil Jenkins" Cc: "Alexey Melnikov" , "IETF JMAP Mailing List" Date: Thu, 11 Jan 2018 17:25:03 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: In-Reply-To: <1515717026.2492419.1232591368.630FE6BF@webmail.messagingengine.com> References: <1513222733.562048.1204501864.2B4A2737@webmail.messagingengine.com> <1515717026.2492419.1232591368.630FE6BF@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8771 signatures=668652 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=932 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120015 Archived-At: Subject: Re: [Jmap] JMAP Core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 01:30:12 -0000 On 11 Jan 2018, at 16:30, Neil Jenkins wrote: > On Fri, 22 Dec 2017, at 10:43 PM, Alexey Melnikov wrote: >> I think value 1 is rather limiting and will prevent the protocol from >> being useful, because clients might have to potentially have multiple >> code paths to cope with maxCallsInRequest == 1 and more capable >> servers. > Based on the feedback in #86[1], I went with a minimum value of 32. > Based on our experience using the protocol, 16 would be fine for > normal > usage, if you think 32 is too high? >> *#89*[2]* Do we need a registry of error types? * >> >> Yes, I think we need to have a registry. I find IANA registries to be >> useful for implementing things and finding out what was already >> registered. > Hmm, the feedback I've had off-list is this is probably not necessary. > I > have gone through RFC 5530[3] to make sure any relevant errors are > covered in the spec, and the consensus seemed to be that entirely new > classes of error were unlikely to appear. It greatly helps client > authors to know the complete set of errors that may be returned to > ensure everything is handled in an appropriate manner; this should > make > that easier. Errors are complex because there are conflicting goals. It's desirable to: * provide machine readable codes to distinguish scenarios where a client may be interested in having a different behavior * provide human readable text for sub-scenarios of a single machine readable code to help resolve problems faster * provide a way to add new machine readable codes in the future without breaking clients, but we prefer not to add codes too often * provide as complete a list as possible of machine readable codes * provide examples of fault scenarios where clients need different behaviors to avoid support calls (e.g., bad user/password vs. service temporarily unavailable) * avoid exposing data over protocol with privacy/security implications unless those implications are trumped by the cost of a support call As long as clients MUST support error codes not defined in the base spec and the behavior for that scenario is documented, I'm ok with deferring registry creation to the first time an error code needs to be added. However, it's not that expensive to create an expert-review registry (a paragraph of text plus registry template) so doing it sooner may remove the need to publish an extra RFC in the future. >>> How do I go about creating a registry presuming we decide we do >>> need one?> I can suggest some text on this. I think the main thing >>> to decide >> first is the registration policy. Do we want some kind of expert >> review for them? > If we do decide to create a registry, I think some kind of expert > review > is reasonable, especially if it's meant to be a new generally > applicable > error that any method could return. My experience is that expert review works best for this sort of registry. - Chris > Neil. From nobody Sun Jan 28 01:01:29 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B89912D944 for ; Sun, 28 Jan 2018 01:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=brNFo0ET; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=anrlMfaz 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 K-3M3J2PPKK5 for ; Sun, 28 Jan 2018 01:01:27 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F20312DA53 for ; Sun, 28 Jan 2018 01:01:27 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CE6C2210F0 for ; Sun, 28 Jan 2018 04:01:26 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 28 Jan 2018 04:01:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=fpr1FqEIZSIWThjmnBZuDz5v1m0dn2tgJXXXVadzu ko=; b=brNFo0ET93AB/meY2LhKTLPeqEQxWRcuVc+eeE89pV5rkb+ZBwhn5NVke +6IefUFpYi2pWYXl7vhXlrtYeoPy8foEeZhI1LDhzTFeRQcyqa5DXb6T0RgHEmU2 ddYS30veK6TZo6TRUt5drTz2s+FudFqodxeZe7/iaeJvr5PronwnXPhcq4C27o70 6B5tQgw3dVoCHrC+1UAXrsTzcISVZ0ED3DzYzh0QJXiM/kkMQoBFNaZkDkavQZYU G9ve5KmV/u7d3rGxRPNeX5mbIeGRZuw0m+TOirMegNs0UzRgIDl8q2IeeVMl4Xpm ieUFCrU4s1r/k213C5+SU7tmUKFEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fpr1FqEIZSIWThjmnBZuDz5v1m0dn 2tgJXXXVadzuko=; b=anrlMfazntGluqVBOkg5Bbb8MOnd6w0MwGulz3AAMiMYm LMN8TnlNDLIua2UgoAvhsYRGJVSK+fnZZkybAqHn5TP6o0FbfeAdv9V72QhhmLAj db0FtkSsNk8H+g9eMu0F4nhftkiUJ2CgKDR1a3kIrWLaQizXxLP3lr6BCu9dm6fQ 0lS0JV38JOouBC2aPb8Rt1B7On22Unfrx5m9MXGI/2ODOrMmC3PRgfGHTLAVa56F SgbPWAhnO+SDbk2EdI9cPSxPIusJu1MrK6KqU/Ll2IRLKSKaj/PVPqO3sl1SMYNs t7Z0QJPpnK6wSRJFx4lPuV8yv6xdYCDG4pOQVpuuQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8E3CF62AF4; Sun, 28 Jan 2018 04:01:26 -0500 (EST) Message-Id: <1517130086.341344.1250606560.743CA23E@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15171300863413441" X-Mailer: MessagingEngine.com Webmail Interface - ajax-20f48d70 Date: Sun, 28 Jan 2018 20:01:26 +1100 Archived-At: Subject: [Jmap] Planning meeting session for IETF101 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 09:01:29 -0000 This is a multi-part message in MIME format. --_----------=_15171300863413441 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, It's time to submit our meeting request for London. I know Barry has some conflicts that he'd like to avoid which have happened to us the past couple of times: So here's the list of conflicts that I'd like to avoid next time. Let me know if there's anything else you want added to the list. I'll submit the session request during the week. Primary blockers: * extra * dispatch * httpbis * uta * oauth * dcrup * doh With secondary against: * saag * tls * ace * lamps * core * quic Does that capture everything everyone cares about? I'm about to send a very similar email to the EXTRA mailing list as well! Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15171300863413441 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

It's time to submit our meeting request for London.  I know Barry has some conflicts that he'd like to avoid which have happened to us the past couple of times:

So here's the list of conflicts that I'd like to avoid next time.  Let me know if there's anything else you want added to the list.  I'll submit the session request during the week.

Primary blockers:

* extra
* dispatch
* httpbis
* uta
* oauth
* dcrup
* doh

With secondary against:
* saag
* tls
* ace
* lamps
* core
* quic

Does that capture everything everyone cares about?

I'm about to send a very similar email to the EXTRA mailing list as well!

Bron.

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


--_----------=_15171300863413441-- From nobody Tue Jan 30 11:46:58 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4ED12FA9B; Tue, 30 Jan 2018 11:46:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, brong@fastmailteam.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151734161801.31788.6732964270701102126.idtracker@ietfa.amsl.com> Date: Tue, 30 Jan 2018 11:46:58 -0800 Archived-At: Subject: [Jmap] jmap - New Meeting Session Request for IETF 101 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 19:46:58 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: extra, dispatch, uta, artarea, dmarc, iasa20, mtgvenue, saag, oauth, dcrup, doh Second Priority: tls, httpbis, ace, lamps, core Third Priority: quic People who must be present: Barry Leiba Alexey Melnikov Bron Gondwana Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Flipcharts: please specify number in Special Requests field Special Requests: One flipchart please --------------------------------------------------------- From nobody Tue Jan 30 11:47:27 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D36512FA9B; Tue, 30 Jan 2018 11:47:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, brong@fastmailteam.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151734164544.31824.18030274948425085325.idtracker@ietfa.amsl.com> Date: Tue, 30 Jan 2018 11:47:25 -0800 Archived-At: Subject: [Jmap] jmap - Update to a Meeting Session Request for IETF 101 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 19:47:25 -0000 An update to a meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: extra dispatch uta artarea dmarc iasa20 mtgvenue saag oauth dcrup doh Second Priority: tls httpbis ace lamps core Third Priority: quic People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Special Requests: One flipchart please --------------------------------------------------------- From nobody Tue Jan 30 11:48:18 2018 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DEA12FAC0; Tue, 30 Jan 2018 11:48:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, brong@fastmailteam.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151734169734.31744.2962591188579168363.idtracker@ietfa.amsl.com> Date: Tue, 30 Jan 2018 11:48:17 -0800 Archived-At: Subject: [Jmap] jmap - Update to a Meeting Session Request for IETF 101 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 19:48:17 -0000 An update to a meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: extra dispatch uta artarea dmarc iasa20 mtgvenue saag oauth dcrup doh Second Priority: tls httpbis ace lamps core Third Priority: quic People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Special Requests: One flipchart please Please avoid Friday as Barry won't be available. --------------------------------------------------------- From nobody Wed Jan 31 13:53:19 2018 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6661012D7EB for ; Wed, 31 Jan 2018 13:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=jWtTtpFM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n4G6EDcC 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 A18xC1y7faXF for ; Wed, 31 Jan 2018 13:53:16 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C4812FAD0 for ; Wed, 31 Jan 2018 13:53:16 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8F2E820C6F for ; Wed, 31 Jan 2018 16:53:15 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Wed, 31 Jan 2018 16:53:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=FRGgYazYAISAWmrZz9DGjzrJ4ImtNnlbgXJXieuKe mo=; b=jWtTtpFMn7fKTOjmwrQEhHzo/MXiE7JKKbzl8fzFQngQyTB1z6OUZbMuO 3ai4rCd/4BujDmIh76PLmbXejgwzizjtqEwWZikeBF/K4j2a+z8LDVM0nG57PIn6 4DVLLx9p/P6IHtqjEFKFWJaU5FnCf2RzWCzAbympTGeKC3EQas7QVklf1HxbWreT RDKJT+Nfme2LJP2E0Gh/Ers/XgEifGhWMeRmQ/CrdqS+yT0juU/oSZDSQdQ/vWlH 7d3WjwZ4Z31A6mYI3oi+lIM1UnZGaxF5ZnzUhlFRMYt6ir8x8dYpwqYudc+UA95w wGnrYOVSxNOjZ34eworjrtQzErucA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=FRGgYazYAISAWmrZz9DGjzrJ4ImtN nlbgXJXieuKemo=; b=n4G6EDcCK+3OnrnTm+z8mL89nGqtuPK05u7QHQGtlgbek Q88tOrjxWn1vfhxZEjeimpj8NeMwDqoB72OYOHIi0ECrUixfAACd+K87hYXH1yVL KW37DtBMnRGSj0zRwsiQoZkkQcFrnMddtUp25E+YquS9SJHRnVK4zHQo+DLT+Zn2 fsMrdcRYFZHQSnb7A9A0mkmII/Szcz0jz0wXOAijl1QmKaXPE5dYA3qTo+m6Ke3M FeR6odsfb8+jt0Tzee889z71NQtJw+pmgVvYE4zo2IOV/yBEzB5jk8G6+SbEDDsq 9d510E+fg4CSoj8yc5hmf6Mu6KN3gC2xspNCesP/g== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 62A08BA43B; Wed, 31 Jan 2018 16:53:15 -0500 (EST) Message-Id: <1517435595.1879314.1255159040.21A78C71@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151743559518793140" X-Mailer: MessagingEngine.com Webmail Interface - ajax-20f48d70 Date: Thu, 01 Feb 2018 08:53:15 +1100 Archived-At: Subject: [Jmap] JMAP added to Hackathon wiki page X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 21:53:18 -0000 This is a multi-part message in MIME format. --_----------=_151743559518793140 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi All, I've added JMAP to the IETF Hackathon page: https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon *JMAP* * Champion(s) * Bron Gondwana * Neil Jenkins * Project(s) * Interoperability testing * Check that spec covers client needs It would be great to have other implementations there to test with! We'll be bringing Cyrus IMAPd, the perl proxy, and Neil's latest frontend code (both the FastMail interface code, and the open source libraries) Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151743559518793140 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi All,

I've added JMAP to the IETF Hackathon page:


JMAP

  • Champion(s)
    • Bron Gondwana
    • Neil Jenkins
  • Project(s)
    • Interoperability testing
    • Check that spec covers client needs

It would be great to have other implementations there to test with!  We'll be bringing Cyrus IMAPd, the perl proxy, and Neil's latest frontend code (both the FastMail interface code, and the open source libraries)

Cheers,

Bron.

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


--_----------=_151743559518793140--