From nobody Fri Oct 19 11:59:09 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 A3D1F1310C3; Fri, 19 Oct 2018 11:56:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: jmap@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997538966.6592.4951459507568890378.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:29 -0700 Archived-At: Subject: [Jmap] jmap - Requested session has been scheduled for IETF 103 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:37 -0000 Dear Barry Leiba, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jmap Session 1 (1:00 requested) Wednesday, 7 November 2018, Afternoon Session I 1350-1520 Room Name: Boromphimarn 3 size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/jmap.ics Request Information: --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: doh dcrup oauth saag iasa2 dmarc artarea uta dispatch extra Second Priority: tls httpbis ace lamps core t2trg People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins 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 of the chairs is not available on Monday, so please schedule later in the week. It would be good to schedule this session next to EXTRA, as many of the same people attend both. --------------------------------------------------------- From nobody Tue Oct 23 02:11:33 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 41F8E12777C; Tue, 23 Oct 2018 02:11:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154028588621.31224.8026931003352086300@ietfa.amsl.com> Date: Tue, 23 Oct 2018 02:11:26 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-09.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 09:11:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSON Meta Application Protocol Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-core-09.txt Pages : 70 Date : 2018-10-23 Abstract: This document specifies a protocol for clients to access JSON-based data objects efficiently, with support for push and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-09 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 23 02:13:39 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 5EB9012777C; Tue, 23 Oct 2018 02:13:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <154028601134.31277.13819627122554872845@ietfa.amsl.com> Date: Tue, 23 Oct 2018 02:13:31 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-09.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 09:13:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Mail Authors : Neil Jenkins Chris Newman Filename : draft-ietf-jmap-mail-09.txt Pages : 89 Date : 2018-10-23 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-09 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 23 02:18:39 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 A0D0A12F1AB for ; Tue, 23 Oct 2018 02:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ESRzrTGF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SE3kt+MS 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 Ek3dFNj8y3zf for ; Tue, 23 Oct 2018 02:18:36 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E788312777C for ; Tue, 23 Oct 2018 02:18:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4439CCD2 for ; Tue, 23 Oct 2018 05:18:34 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 23 Oct 2018 05:18:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=uHFSKi3tlD8IiteHBOdc54n5TSnNxLQRnqb0bBc wsBQ=; b=ESRzrTGF1a+iNEUvMBKz/r3oc6oIsSVbKPzU5eAC8WL5norCSh9AgVS JFSn2OtR7GAPg2fwbj5sapdG2Wm5EuXyjXYsxOTUq3Adi0wRMjq1CDPzLkN2/x+N r0z5taOIeV4wDBnYxIypEJ6JGaKnPHVHj9L+RjEf8T6ZOY9nysuyqdBFknRkwxDj FuvPls9IH3GWk8AeznSxVTMfQQD9cwV9uJmnDC4xO8wgDBA1Ggrd4q+XK5PfMdMe RYFPIRpITsh8JVpLUGfseGmkqCo7rV7cbddMToCJIUT9/LBnhyCjySV+YM7bvIQW Vm8oxxvNZfgMNbe2e6onyagRpK+fiLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=uHFSKi3tlD8IiteHBOdc54n5TSnNxLQRnqb0bBcwsBQ=; b=SE3kt+MS Bdw54in1rq9FsimW/thjI9jHhCAB14gcTdTtjkXY9439kpzFcH6+L6/Y4pRwXwsN fISAnaC6lbg9FD2IEpwX8GpqZCuSsYQlCQQ5laHJwQ3xVS9XGTTXeIzERg2mzx3+ +BkWYL3qkcJR14xLndn3+RbD2WhRxXF0QbqjfMoM3q+DABwB82Nzlz67aImPZqHT duWkVPeHCoO004BFDhYdgahypK7WQglzcnGzMZKu+vd+hxLKKImm8uj/ogytX9yN cf4sX4rUcJu0MPrqoEaHsejfXAFzs0TacMIXQrLbDno/yKBd7q4rW24Y5LgN5qrh k3yRsOFva9ilJg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2DE532092C; Tue, 23 Oct 2018 05:18:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <3c02785f-ffb0-477a-baeb-c47944614ecd@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-552-g4f5efa9-fmnext-20181016v1 X-Me-Personality: 64588216 Date: Tue, 23 Oct 2018 05:18:10 -0400 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=58d7c296371f4a25a6c1700df35818df Archived-At: Subject: [Jmap] Reminder: last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 09:18:38 -0000 --58d7c296371f4a25a6c1700df35818df Content-Type: text/plain Hi all, Just a reminder that we're in last call for the JMAP core + mail specs; I've just uploaded new revisions with some minor changes based on the feedback so far. With IETF103 less than 2 weeks away, now would be a great time to do your final review so we can discuss any outstanding items at the meeting before the last call closes on 16th November. Latest spec links again: Core: https://tools.ietf.org/html/draft-ietf-jmap-core-09 Mail: https://tools.ietf.org/html/draft-ietf-jmap-mail-09 Cheers, Neil. --58d7c296371f4a25a6c1700df35818df Content-Type: text/html
Hi all,

Just a reminder that we're in last call for the JMAP core + mail specs; I've just uploaded new revisions with some minor changes based on the feedback so far. With IETF103 less than 2 weeks away, now would be a great time to do your final review so we can discuss any outstanding items at the meeting before the last call closes on 16th November.

Latest spec links again:


Cheers,
Neil.
--58d7c296371f4a25a6c1700df35818df-- From nobody Thu Oct 25 17:58:14 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 B233E130E08; Thu, 25 Oct 2018 17:58:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i7PpXNEQ9RQ; Thu, 25 Oct 2018 17:58:10 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 69E5B1286E7; Thu, 25 Oct 2018 17:58:10 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id w19-v6so10174492eds.1; Thu, 25 Oct 2018 17:58:10 -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=vYv3baw+iUilpFIbuJeqQUBx5NDF0saZHWF6IaUeDH4=; b=sWv7W8QEJespj3futdEcWNIOl7eRIUR3Z2UIXHNj7sUWAYbg4kxTAY0HIOyzDCmEv7 p7/nI5eTbgBqTg1tlWHRHhcZCUgZKD8FqrgPu2Eanw4QVd07mE9hcVcqNgMLe/PQSpWm lnDulI/EmX+O+gJur8SF5sVJc5+4rTZv8jhLZNeHr9RvhbhXuFAMlkL8+wJZagw5K7b4 e7c1IH92o3FhA9y0rmZFaDbW9THMDYHkSS2I+T/My3+FnrsXkH9GHJbGvJvP9Y62DUjQ VRm5DU3rC5yZI1mLh/cNwWs4b7ldv/luDWXXJoGrCa72BBsgje9KJyvsQ2yojb7SHwPl pM1w== 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=vYv3baw+iUilpFIbuJeqQUBx5NDF0saZHWF6IaUeDH4=; b=bVEvs7xHiRZaTIQCYf0XbVfySkaVQFSbUNlUDv8Mv2imnGOI7mlHaSgB5q13G0aMub hn6gaiSiNbX23E2j05cwsTSuPIpW9d1LiZgs4S2fMRhEXshtZ2gLs6N2D1Dkb6unyhof FN7GY5wqTjjCdFpezNVVgbP+aVPVjXEraNF+FwAWFvnTv/V9sF6CTXUV/mvZ/WvBzU+y 7xUa04jdeQgd/yyk5Ujx0iRiGkvq6lSSPnWCEIDLbe3pLlDCIj0RsAZhTaOr9/1b7PC1 wNF3iAiiHCFYC6uoTB25q/vpO/8yZfDt0gRlln4s5/v/mvQGr2REYXhxSSdYW+Ax1RpT K87A== X-Gm-Message-State: AGRZ1gJRunTd4BDIP9tthH9Aci1FeCFrK7hgwJWUYmtv7zb/nXO1c1ov C80iGn7Vx9rb4Fw/PRPpU2KlzH4OEMNZZ+3FQqIgT8Nk9as= X-Google-Smtp-Source: AJdET5dCDhKTIwHs8KQVIzzF282ZyncYBmpGIpMzA1Bcdq1FcsZWp27jE1OQQeAluEHoly42wtINQmGgx2cngSe7skY= X-Received: by 2002:aa7:c149:: with SMTP id r9-v6mr1019788edp.213.1540515488512; Thu, 25 Oct 2018 17:58:08 -0700 (PDT) MIME-Version: 1.0 From: Todd Hubers Date: Fri, 26 Oct 2018 11:57:56 +1100 Message-ID: To: jmap@ietf.org, doh@ietf.org Content-Type: multipart/alternative; boundary="00000000000076bde2057917369c" Archived-At: Subject: [Jmap] Web Convergence - is there a document/RFC for this apparent direction? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 00:58:13 -0000 --00000000000076bde2057917369c Content-Type: text/plain; charset="UTF-8" Hi All, Is there a document/RFC about the IETFs collective general movement toward re-standardisation of things like DNS (DOH), SMTP (JMAP), and maybe others using Web/HTTP/JSON? I read the introduction of DoH [RFC8484], and noted there was no reference there, so such a document probably doesn't exist. Instead, it could read something like "Web Convergence is desirable [RFCXXXX]", and that RFC could be very comprehensive in the collective decision about this direction. It would critically help in determining when a current standard should be considered for Web Convergence. I believe it would be something to be referenced in the charter of such a WG, to clarify WHY the work is being completed, in addition to the other good reasons. Even if we don't have an RFC, this idea does need a solid name/label. I have initial ideas for the content of such a Web Convergence RFC [Appendix 1], and what it might be ultimately called [Appendix 2] (I am also new to IETF generally, so I'm still learning. But I like learning by doing._ Thanks, Todd Hubers --- Appendix 1 For rebuilding of older standards the web way; OR, building new standards the web way. The reasons should be the same. Initial ideas for reasons to be collated in such a document/rfc: - Accessible directly by web applications (javascript), removing the need to push via a specialised application server adaptor service (eg. HTTP to SMTP) - The reuse of standard web sysops tools (eg. nginx, certificate management, services like CloudFlare and more) - The reuse of standard web frameworks and libraries (eg. header parsing, asynchronous threads) - Reducing the diffusion of open source development contribution (redefining the same functions in different standards, and different source code is inefficient). - Additional features available from current and future web standards (eg. redirect, media-type negotiation, compression, multiplexing, proxying, caching, authentication, Header Parsing, URIs, well-named folders, Identity, Semantics, etc..) - More secure with exactly the same security model as web - (eg. no plain text email transmission) - All security/firewalls leveraging accumulated PORT 80/443 and HTTP intelligence. --- Appendix 2 Possible names for this process - Web Recasting - Web Convergence - Http Convergence (specifically HTTP of Web Convergence) --00000000000076bde2057917369c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2= =A0All,

Is there a document/RFC about the IETFs=C2=A0col= lective general movement toward re-standardisation of things like DNS (DOH)= , SMTP (JMAP), and maybe others using Web/HTTP/JSON?

I read the introduction of DoH [RFC8484], and noted there was no ref= erence there, so such a document probably doesn't exist.=C2=A0

Instead,=C2=A0it could read something like "Web Conve= rgence is desirable [RFCXXXX]", and that RFC could be very comprehensi= ve in the collective decision about this direction. It would critically hel= p in determining when a current standard should be considered for Web Conve= rgence.

I believe it would be something to be refe= renced in the charter of such a WG, to clarify WHY the work is being comple= ted, in addition to the other good reasons. Even if we don't have an RF= C, this idea does need a solid name/label.

I have = initial ideas for the content of such a Web Convergence RFC [Appendix 1], a= nd what it might be ultimately called [Appendix 2]

(I am also new to IETF generally, so I'm still learning. But I like le= arning by doing._

Thanks,
=

Todd Hubers

---

Appendix 1

For= rebuilding of older standards the web way; OR, building new standards the = web way. The reasons should be the same.

Ini= tial ideas for reasons to be collated in such a document/rfc:

- Accessible directly by web applications (javascript)= , removing the need to push via a specialised application server adaptor se= rvice (eg. HTTP to SMTP)
- The reuse of standard web sysops t= ools (eg. nginx, certificate management, services like CloudFlare and more)=
- The reuse of standard web frameworks and libraries (eg. header= parsing, asynchronous threads)
- Reducing the diffusion of open = source development contribution (redefining the same functions in different= standards, and different source code is inefficient).
- Addition= al features available from current and future web standards (eg. redirect, = media-type negotiation, compression, multiplexing, proxying, caching, authe= ntication, Header Parsing, URIs, well-named folders, Identity, Semantics, e= tc..)
- More secure with exactly the same security model as web -= (eg. no plain text email transmission)
- All security/firewalls = leveraging accumulated PORT 80/443 and HTTP intelligence.=C2=A0=C2=A0
=

---

Appendix 2

Possible names for this process

- Web Recasting
- Web Convergence
- Http Conve= rgence (specifically HTTP of Web Convergence)
= --00000000000076bde2057917369c-- From nobody Thu Oct 25 18:30:59 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 CE051130DC1; Thu, 25 Oct 2018 18:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 ip3TWbDen8bC; Thu, 25 Oct 2018 18:30:49 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0096.outbound.protection.outlook.com [104.47.93.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F2C1294D7; Thu, 25 Oct 2018 18:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IGIeqldCg/k5bRpZZSh9pbMdtrusa48f1eXk2Thy5ZA=; b=t+WF5GdY1XIO9w4nZQ3njvjFfdTwd+ccZHrOcmb1lN5G/P2RROnxVNaKOtASYvtVGOrhPRhu4SE1kQFwMi4/RpNrzYlCiaFul/GJOuiyaelyCxe5n1tKsuDQFFSeAY7zXMZI9gqcsPyCJxuJhv53NDKrgDftrXYknrkANeqIoIU= Received: from TY1PR01MB1547.jpnprd01.prod.outlook.com (52.133.162.14) by TY1PR01MB0778.jpnprd01.prod.outlook.com (10.167.158.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.20; Fri, 26 Oct 2018 01:30:46 +0000 Received: from TY1PR01MB1547.jpnprd01.prod.outlook.com ([fe80::883f:aaf4:50da:73a6]) by TY1PR01MB1547.jpnprd01.prod.outlook.com ([fe80::883f:aaf4:50da:73a6%3]) with mapi id 15.20.1273.025; Fri, 26 Oct 2018 01:30:46 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Todd Hubers , "jmap@ietf.org" , "doh@ietf.org" Thread-Topic: [Doh] Web Convergence - is there a document/RFC for this apparent direction? Thread-Index: AQHUbMcCrD2p+NvHbUCOXnpVhAOWD6UwvXsA Date: Fri, 26 Oct 2018 01:30:46 +0000 Message-ID: <824fc208-1295-7aba-5601-314c66ec51c7@it.aoyama.ac.jp> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: TY1PR01CA0141.jpnprd01.prod.outlook.com (2603:1096:402:1::17) To TY1PR01MB1547.jpnprd01.prod.outlook.com (2603:1096:403:4::14) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY1PR01MB0778; 6:Y0A6wo4RyCm79/XcJS7qDvgNbKi/PACf5GEPRZEtsRNPDp1+u7ixVYF71mjReq0Wt2QHBperjhpt8DER98XvG3EuOrNceDpH3n6CwOC/eKy8nHfrHNzne2RFNvauIH9XieVy088Z30905z3ZFIo5DqNRQSMhBXMPru8aMEJPgzKZXiw/IKENOgp4CrO4DCYIu9X0oIOY3WsK8AzkU5PWJ2ryIHTTuxvJ9l/s/1xWRzInmgTnvJiV9kEuJMODMVWuNFVSmqP6sNUcHVy881Rowcf5ETdkyWeW3Y1Qvx+JFr/eIAP0V9BPJK4fItNqHHTYIa6Dkp2k5uJsGu3PGKEV89fjJ2mBGupCqekRk9ers5phCIyI53BSn9HfjyF2oY+QiJpkXLB6/CGzI06W+gTQV0yblisVtmSMdr849RtB5ILPIyKum+856pvzXa8KPo6nPQbesWht/TYMpUb9JHA6Bg==; 5:dwDcgB1GOw3GsYKL46A8xnYuWSw2vaVhcat83lI1TR3JIQs8zzc13LsfSDj4Riqu91j2CRFqjT/RbD4ymhUzGblDaIn9iVq2Oi2wWKlAKsQlPTZ8bUxeZ19fZQFofz2VIa5coPuDJz9uGVeYLOk5Jqvj7M7HNYbxAz/I5rC+Kbo=; 7:gmHCm2bIbODycX0EXmkbC5mMIU4NsQ45R7ma1I4HgH4NU8aKaiSsQZD0ubugM9rpF5555uP2sqP8rohxAT3OdwWxgc/zAGyhoSScpPEU/pnOA7a721gZm+Cue+ccEWXC5LfANLLWsIOnc/rd43T/UHLNN51sfqK9XZ/I8h2NpM9Iy2m9wXPk6NB1fvRHnVJNk2WYBINml4sgwSnw75Xu+hpxbSR5q6q/QWLJJwSyd+6SpLmvYjDv6+NRHffmUXLK x-ms-office365-filtering-correlation-id: f097df54-5750-4224-0759-08d63ae2a717 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7025125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:TY1PR01MB0778; x-ms-traffictypediagnostic: TY1PR01MB0778: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(278428928389397)(158342451672863)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(4982022)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(2016111802025)(20161123560045)(20161123564045)(6043046)(201708071742011)(7699051)(76991095); SRVR:TY1PR01MB0778; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0778; x-forefront-prvs: 083751FCA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39840400004)(366004)(376002)(346002)(396003)(53754006)(199004)(189003)(229853002)(8676002)(81156014)(81166006)(305945005)(14444005)(186003)(7736002)(66066001)(76176011)(2201001)(102836004)(52116002)(26005)(446003)(11346002)(256004)(8936002)(68736007)(3846002)(6116002)(2906002)(476003)(2616005)(110136005)(486006)(53546011)(6506007)(386003)(6436002)(99286004)(6486002)(5660300001)(25786009)(966005)(74482002)(105586002)(106356001)(85202003)(31686004)(508600001)(2900100001)(39060400002)(71190400001)(71200400001)(53936002)(316002)(6512007)(786003)(31696002)(6306002)(85182001)(86362001)(97736004)(5250100002)(14454004)(6246003)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0778; H:TY1PR01MB1547.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: /Zla1z+BQJWk7VREAlhzyLECO6CqGmbZs8BIp3VnbNmFzpd/VJyR2uyqL7sa52w6gyGh7n2rPQf6KdMWiI7nXLyLwpotnZSdY4FILhuvvRsU52zhwe//za+ehe06I0ZzELfSffzFbGp1ZexojbKqSd5P6k34/rBTo7phwsSVnKD5BEeycDwx5Q4wY90t5bNX9t5i5I53+78qoiDwuy5DkgbscFQq4r2bsOQWLZyH5DfgSNpOcL/6GNljJg6UHz+zk/etUO4qyxlQBKHqfOBNaHTlXsvjluubiy6RhZ5PvB4r9CkPn+Bqk8BfsSWQVDV4D57gWixXlG5aJdKEU16aLjyd3FsPtTzxV6XK2jATlUU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <38CEF41361ED1E4A8706F1CFADA04880@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: f097df54-5750-4224-0759-08d63ae2a717 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2018 01:30:46.3150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0778 Archived-At: Subject: Re: [Jmap] [Doh] Web Convergence - is there a document/RFC for this apparent direction? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 01:30:52 -0000 SGVsbG8gVG9kZCwNCg0KVGhpcyBpcyBqdXN0IGEgcGVyc29uYWwgb3BpbmlvbiwgYnV0IGJhc2Vk IG9uIG1vcmUgdGhhbiAyMCB5ZWFycyBvZiANCmV4cGVyaWVuY2Ugd2l0aCB2YXJpb3VzIHN0YW5k YXJkcyBvcmdhbml6YXRpb25zIGluY2x1ZGluZyB0aGUgSUVURi4NCg0KT24gMjAxOC8xMC8yNiAw OTo1NywgVG9kZCBIdWJlcnMgd3JvdGU6DQo+IEhpIEFsbCwNCj4gDQo+IElzIHRoZXJlIGEgZG9j dW1lbnQvUkZDIGFib3V0IHRoZSBJRVRGcyBjb2xsZWN0aXZlIGdlbmVyYWwgbW92ZW1lbnQgdG93 YXJkDQo+IHJlLXN0YW5kYXJkaXNhdGlvbiBvZiB0aGluZ3MgbGlrZSBETlMgKERPSCksIFNNVFAg KEpNQVApLCBhbmQgbWF5YmUgb3RoZXJzDQo+IHVzaW5nIFdlYi9IVFRQL0pTT04/DQo+IA0KPiBJ IHJlYWQgdGhlIGludHJvZHVjdGlvbiBvZiBEb0ggW1JGQzg0ODRdLCBhbmQgbm90ZWQgdGhlcmUg d2FzIG5vIHJlZmVyZW5jZQ0KPiB0aGVyZSwgc28gc3VjaCBhIGRvY3VtZW50IHByb2JhYmx5IGRv ZXNuJ3QgZXhpc3QuDQoNCkkgZ3Vlc3MgeW91J3JlIHJpZ2h0LiBCdXQgdGhlcmUgbWF5IGJlIGRv Y3VtZW50cyB0aGF0IGFyZSBzb21ld2hhdCANCnJlbGF0ZWQuIEluIHBhcnRpY3VsYXIsIEknbSB0 aGlua2luZyBvZiANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aHR0cGJpcy1iY3A1NmJpcy8uDQoNCj4gSW5zdGVhZCwgaXQgY291bGQgcmVhZCBzb21ldGhpbmcg bGlrZSAiV2ViIENvbnZlcmdlbmNlIGlzIGRlc2lyYWJsZQ0KPiBbUkZDWFhYWF0iLCBhbmQgdGhh dCBSRkMgY291bGQgYmUgdmVyeSBjb21wcmVoZW5zaXZlIGluIHRoZSBjb2xsZWN0aXZlDQo+IGRl Y2lzaW9uIGFib3V0IHRoaXMgZGlyZWN0aW9uLiBJdCB3b3VsZCBjcml0aWNhbGx5IGhlbHAgaW4g ZGV0ZXJtaW5pbmcgd2hlbg0KPiBhIGN1cnJlbnQgc3RhbmRhcmQgc2hvdWxkIGJlIGNvbnNpZGVy ZWQgZm9yIFdlYiBDb252ZXJnZW5jZS4NCg0KVGhlIElFVEYgaXMgKGF0IGxlYXN0IG9mZmljaWFs bHkpIGEgY29sbGVjdGlvbiBvZiBpbmRpdmlkdWFscy4gTWFueSBvZiANCnRoZXNlIGluZGl2aWR1 YWxzIHNlZSB0cmVuZHMgbGlrZSB0aGUgb25lIHlvdSBicmluZyB1cCBoZXJlLiBCdXQgdGhlIA0K SUVURiBhcyBhIHdob2xlIGlzbid0IG9yZ2FuaXplZCBvciBlbXBvd2VyZWQgdG8gYWRhcHQgZ3Jl YXQgdHJlbmRzIGFuZCANCnRoZW4gZm9yY2UgZXZlcnlib2R5IHRvIGZvbGxvdyB0aGVtLiBXaGVy ZSB0aGF0IGhhcyBiZWVuIHRyaWVkLCBpdCBoYXMgDQp1c3VhbGx5IG5vdCB3b3JrZWQgZXh0cmVt ZWx5IHdlbGwuDQoNCk90aGVyIHN0YW5kYXJkcyBvcmdhbml6YXRpb25zIG1heSBkbyBtb3JlIG9m IHN1Y2ggIm92ZXJhbGwgZGlyZWN0aW9uIiANCmRvY3VtZW50cywgYnV0IGluIGdlbmVyYWwsIEkg ZG9uJ3QgdGhpbmsgdGhleSBoYXZlIHRvbyBtdWNoIHN1Y2Nlc3Mgd2l0aCANCnRoZW0uDQoNCj4g SSBiZWxpZXZlIGl0IHdvdWxkIGJlIHNvbWV0aGluZyB0byBiZSByZWZlcmVuY2VkIGluIHRoZSBj aGFydGVyIG9mIHN1Y2ggYQ0KPiBXRywgdG8gY2xhcmlmeSBXSFkgdGhlIHdvcmsgaXMgYmVpbmcg Y29tcGxldGVkLCBpbiBhZGRpdGlvbiB0byB0aGUgb3RoZXINCj4gZ29vZCByZWFzb25zLiBFdmVu IGlmIHdlIGRvbid0IGhhdmUgYW4gUkZDLCB0aGlzIGlkZWEgZG9lcyBuZWVkIGEgc29saWQNCj4g bmFtZS9sYWJlbC4NCg0KV0dzIGdldCBmb3JtZWQgYmVjYXVzZSBlbm91Z2ggaW5kaXZpZHVhbHMg KGFuZCBvZnRlbiBjb21wYW5pZXMgdGhhdCANCmVtcGxveSB0aGVtKSBhcmUgaW50ZXJlc3RlZCBp biBnZXR0aW5nIHNvbWUgc3RhbmRhcmRpemF0aW9uIHdvcmsgZG9uZS4gDQpUaGF0IHdvcmsgbWF5 IGJlIHdheSBhaGVhZCBvZiBhIHRyZW5kLCBtYXkgYmUgaW4gb25lIG9mIHRoZSBjdXJyZW50IA0K dHJlbmRzLCBtYXkgYmUgd2F5IGJlaGluZCBhIHRyZW5kLCBvciBjb21wbGV0ZWx5IHVucmVsYXRl ZCB0byBhbnkgdHJlbmQuDQoNCj4gSSBoYXZlIGluaXRpYWwgaWRlYXMgZm9yIHRoZSBjb250ZW50 IG9mIHN1Y2ggYSBXZWIgQ29udmVyZ2VuY2UgUkZDDQo+IFtBcHBlbmRpeCAxXSwgYW5kIHdoYXQg aXQgbWlnaHQgYmUgdWx0aW1hdGVseSBjYWxsZWQgW0FwcGVuZGl4IDJdDQo+IA0KPiAoSSBhbSBh bHNvIG5ldyB0byBJRVRGIGdlbmVyYWxseSwgc28gSSdtIHN0aWxsIGxlYXJuaW5nLiBCdXQgSSBs aWtlDQo+IGxlYXJuaW5nIGJ5IGRvaW5nLl8NCg0KRXZlcnlib2R5IChpbmNsdWRpbmcgeW91KSBj YW4gc3VibWl0IGFuIEludGVybmV0IERyYWZ0IChleGNlcHQgdGhpcyANCndlZWspLiBTbyB3cml0 aW5nIHVwIHlvdXIgaWRlYXMgYW5kIHN1Ym1pdHRpbmcgYSBkcmFmdCBtYXkgYmUgYSBnb29kIA0K aWRlYS4gTXkgcGVyc29uYWwgYWR2aWNlIHdvdWxkIGJlIHRvIGJlIG1vcmUgZGVzY3JpcHRpdmUg YW5kIGxlc3MgDQpwcmVkaWN0aXZlIG9yIHByZXNjcmlwdGl2ZS4NCg0KUmVnYXJkcywgICBNYXJ0 aW4uDQoNCj4gVGhhbmtzLA0KPiANCj4gVG9kZCBIdWJlcnMNCj4gDQo+IC0tLQ0KPiANCj4gQXBw ZW5kaXggMQ0KPiANCj4gRm9yIHJlYnVpbGRpbmcgb2Ygb2xkZXIgc3RhbmRhcmRzIHRoZSB3ZWIg d2F5OyBPUiwgYnVpbGRpbmcgbmV3IHN0YW5kYXJkcw0KPiB0aGUgd2ViIHdheS4gVGhlIHJlYXNv bnMgc2hvdWxkIGJlIHRoZSBzYW1lLg0KPiANCj4gSW5pdGlhbCBpZGVhcyBmb3IgcmVhc29ucyB0 byBiZSBjb2xsYXRlZCBpbiBzdWNoIGEgZG9jdW1lbnQvcmZjOg0KPiANCj4gLSBBY2Nlc3NpYmxl IGRpcmVjdGx5IGJ5IHdlYiBhcHBsaWNhdGlvbnMgKGphdmFzY3JpcHQpLCByZW1vdmluZyB0aGUg bmVlZA0KPiB0byBwdXNoIHZpYSBhIHNwZWNpYWxpc2VkIGFwcGxpY2F0aW9uIHNlcnZlciBhZGFw dG9yIHNlcnZpY2UgKGVnLiBIVFRQIHRvDQo+IFNNVFApDQo+IC0gVGhlIHJldXNlIG9mIHN0YW5k YXJkIHdlYiBzeXNvcHMgdG9vbHMgKGVnLiBuZ2lueCwgY2VydGlmaWNhdGUNCj4gbWFuYWdlbWVu dCwgc2VydmljZXMgbGlrZSBDbG91ZEZsYXJlIGFuZCBtb3JlKQ0KPiAtIFRoZSByZXVzZSBvZiBz dGFuZGFyZCB3ZWIgZnJhbWV3b3JrcyBhbmQgbGlicmFyaWVzIChlZy4gaGVhZGVyIHBhcnNpbmcs DQo+IGFzeW5jaHJvbm91cyB0aHJlYWRzKQ0KPiAtIFJlZHVjaW5nIHRoZSBkaWZmdXNpb24gb2Yg b3BlbiBzb3VyY2UgZGV2ZWxvcG1lbnQgY29udHJpYnV0aW9uDQo+IChyZWRlZmluaW5nIHRoZSBz YW1lIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgc3RhbmRhcmRzLCBhbmQgZGlmZmVyZW50IHNvdXJj ZQ0KPiBjb2RlIGlzIGluZWZmaWNpZW50KS4NCj4gLSBBZGRpdGlvbmFsIGZlYXR1cmVzIGF2YWls YWJsZSBmcm9tIGN1cnJlbnQgYW5kIGZ1dHVyZSB3ZWIgc3RhbmRhcmRzIChlZy4NCj4gcmVkaXJl Y3QsIG1lZGlhLXR5cGUgbmVnb3RpYXRpb24sIGNvbXByZXNzaW9uLCBtdWx0aXBsZXhpbmcsIHBy b3h5aW5nLA0KPiBjYWNoaW5nLCBhdXRoZW50aWNhdGlvbiwgSGVhZGVyIFBhcnNpbmcsIFVSSXMs IHdlbGwtbmFtZWQgZm9sZGVycywNCj4gSWRlbnRpdHksIFNlbWFudGljcywgZXRjLi4pDQo+IC0g TW9yZSBzZWN1cmUgd2l0aCBleGFjdGx5IHRoZSBzYW1lIHNlY3VyaXR5IG1vZGVsIGFzIHdlYiAt IChlZy4gbm8gcGxhaW4NCj4gdGV4dCBlbWFpbCB0cmFuc21pc3Npb24pDQo+IC0gQWxsIHNlY3Vy aXR5L2ZpcmV3YWxscyBsZXZlcmFnaW5nIGFjY3VtdWxhdGVkIFBPUlQgODAvNDQzIGFuZCBIVFRQ DQo+IGludGVsbGlnZW5jZS4NCj4gDQo+IC0tLQ0KPiANCj4gQXBwZW5kaXggMg0KPiANCj4gUG9z c2libGUgbmFtZXMgZm9yIHRoaXMgcHJvY2Vzcw0KPiANCj4gLSBXZWIgUmVjYXN0aW5nDQo+IC0g V2ViIENvbnZlcmdlbmNlDQo+IC0gSHR0cCBDb252ZXJnZW5jZSAoc3BlY2lmaWNhbGx5IEhUVFAg b2YgV2ViIENvbnZlcmdlbmNlKQ0KPiANCg== From nobody Thu Oct 25 18:57:24 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 14CAB126CC7; Thu, 25 Oct 2018 18:57:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtfJ_rs6j13M; Thu, 25 Oct 2018 18:57:20 -0700 (PDT) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (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 CAA6D1294D7; Thu, 25 Oct 2018 18:57:19 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id v18-v6so2625076edq.13; Thu, 25 Oct 2018 18:57:19 -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=nyrNlPrxJe+FLVfc53JtdK2MzaquxCs7zejUeRWgWcM=; b=Mtva/qpv1dUNy4E8AnU0BVRYcGeW8VCmfijY3TI2VyijzI/mNrJj7vZN4LrNgpbeJo PYUyizcPUAgTo/f2qaNVoeqGKUfLOkAMTvt42zKpl1PvzQLpKXVocHTXZ6cBABqzEgZv PRhvBLXS1Ifaz3B4XU8ukihq8NldG9I3/x8rHfDBlstZ3XdQjTzRPNqtvwEqfmE/QkS0 BVPEVANCgA+ZXLyjpMlTFAaj2iatNarr/LBgQorLSwcBasqEiQLIJgVjdcZWjqOnTL3e TOCZcXPxmFr8sMmafLrXYcO9ZsYF+KYR9NBa4G9mo+vc6Q6B8AgAcO/DX7pLkhJEGERm 39Nw== 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=nyrNlPrxJe+FLVfc53JtdK2MzaquxCs7zejUeRWgWcM=; b=q/Cdg7fm98dTRj9eqlYsG/c+dwgZMCMfP76Cfwpoj9cSf6msLetW1bsedLvrh75asf +IRi7VdCMw6gZqdgh8u6h5geaekUcG42fH9BeQhY8qOSdqJXXU9GyzCbUckLgBhgq0lc bmTyd8/N+7QyDQgdLTQWMc/gZpTNlhE9eryMsEUocxdoJ9B24RiJyUIZLx8vzEQJvBsj Y3vZvPGRDuG3iNOPjbm6AZuTg38EQbaGbiCu2GkJD5U3x0Pz1ajufpFQrqCJBl6gdYwf prwcmKB6xTm6Xk/H7aP/vjmlmVwRl2Fs4EjPcxYAt+M3mtmcFWN3VR4USufswtfsQH5i qVyw== X-Gm-Message-State: AGRZ1gL7Tk+ySAWaFp6MUetYWylQFMwjeeehCx/QFP69rn6d0ZDWf2DR dUEk1s0HjxKX4u7F/1DjaZR1yUBFUhbZV8o7LgsQwjjYCiA= X-Google-Smtp-Source: AJdET5cLWhmGcpztTxNdiqa724sTzll6QLoUaXLKZrQqirf/egZRsBfrkpXucH8nlA2lXVNqWHYtnIp8ob9WBuFif/o= X-Received: by 2002:a17:906:2899:: with SMTP id o25-v6mr899659ejd.53.1540519038084; Thu, 25 Oct 2018 18:57:18 -0700 (PDT) MIME-Version: 1.0 References: <824fc208-1295-7aba-5601-314c66ec51c7@it.aoyama.ac.jp> In-Reply-To: <824fc208-1295-7aba-5601-314c66ec51c7@it.aoyama.ac.jp> From: Todd Hubers Date: Fri, 26 Oct 2018 12:57:05 +1100 Message-ID: To: duerst@it.aoyama.ac.jp Cc: jmap@ietf.org, doh@ietf.org Content-Type: multipart/alternative; boundary="00000000000008ea730579180a02" Archived-At: Subject: Re: [Jmap] [Doh] Web Convergence - is there a document/RFC for this apparent direction? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 01:57:23 -0000 --00000000000008ea730579180a02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, Thanks for your time. At the very least, I seek validation of the necessity for this from others, while I refine my communication of the ideas I'm trying to express. I have been reading a lot of material, and also the intro youtube videos. So I do have a good grasp of the correct approach. I understand the fundamental principles of no voting etc., This is why I was careful to write "collective decision of direction" - such a direction isn't necessarily conscious/formal. However, It would have been better if I wrote "..that RFC could be very comprehensive in cataloguing the reasons why Web Convergence is desirable...". I don't expect such a document to be prescriptive at all. As you say, there is no "decision", although there is an observed "direction" in some IETF proposals and in the industry broadly; this is a tool for decision making and a reference for brevity. It would be a body of work that could be referenced, helping to establish why any organisation would write their standard leveraging Web Standards (and why not). https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ is a fantastic reference, this is exactly the kind of document I was hoping to find. It's a great starting point, if not the exact thing, I was describing. I'll need to spend time and read it in more detail. It might need to be broadened to "Web"; either directly or via a separate new Internet Draft. JMAP is a good example of why such broadening may be useful: The JMAP standard document doesn't actually reference HTTP, I believe it's more about JSON schema than HTTP mechanisms (or perhaps such mechanisms are in other standards that I haven't read yet) - although the charter does mention HTTP - perhaps HTTP is a missing component from the JMAP standard. If I had a fresh stab of a description of a new Internet Draft, it would be "Choosing whether or not to build new standards upon Web Standards". The title "Web Convergence" is probably too prescriptive, "Building Protocols with Web Standards" might be an appropriate title, or "Building Standards based on Web Standards". So with my clarifications above, I would welcome any further criticisms or support, to help guide me in coming weeks. Thanks, Todd On Fri, 26 Oct 2018 at 12:30, Martin J. D=C3=BCrst wrote: > Hello Todd, > > This is just a personal opinion, but based on more than 20 years of > experience with various standards organizations including the IETF. > > On 2018/10/26 09:57, Todd Hubers wrote: > > Hi All, > > > > Is there a document/RFC about the IETFs collective general movement > toward > > re-standardisation of things like DNS (DOH), SMTP (JMAP), and maybe > others > > using Web/HTTP/JSON? > > > > I read the introduction of DoH [RFC8484], and noted there was no > reference > > there, so such a document probably doesn't exist. > > I guess you're right. But there may be documents that are somewhat > related. In particular, I'm thinking of > https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/. > > > Instead, it could read something like "Web Convergence is desirable > > [RFCXXXX]", and that RFC could be very comprehensive in the collective > > decision about this direction. It would critically help in determining > when > > a current standard should be considered for Web Convergence. > > The IETF is (at least officially) a collection of individuals. Many of > these individuals see trends like the one you bring up here. But the > IETF as a whole isn't organized or empowered to adapt great trends and > then force everybody to follow them. Where that has been tried, it has > usually not worked extremely well. > > Other standards organizations may do more of such "overall direction" > documents, but in general, I don't think they have too much success with > them. > > > I believe it would be something to be referenced in the charter of such= a > > WG, to clarify WHY the work is being completed, in addition to the othe= r > > good reasons. Even if we don't have an RFC, this idea does need a solid > > name/label. > > WGs get formed because enough individuals (and often companies that > employ them) are interested in getting some standardization work done. > That work may be way ahead of a trend, may be in one of the current > trends, may be way behind a trend, or completely unrelated to any trend. > > > I have initial ideas for the content of such a Web Convergence RFC > > [Appendix 1], and what it might be ultimately called [Appendix 2] > > > > (I am also new to IETF generally, so I'm still learning. But I like > > learning by doing._ > > Everybody (including you) can submit an Internet Draft (except this > week). So writing up your ideas and submitting a draft may be a good > idea. My personal advice would be to be more descriptive and less > predictive or prescriptive. > > Regards, Martin. > > > Thanks, > > > > Todd Hubers > > > > --- > > > > Appendix 1 > > > > For rebuilding of older standards the web way; OR, building new standar= ds > > the web way. The reasons should be the same. > > > > Initial ideas for reasons to be collated in such a document/rfc: > > > > - Accessible directly by web applications (javascript), removing the ne= ed > > to push via a specialised application server adaptor service (eg. HTTP = to > > SMTP) > > - The reuse of standard web sysops tools (eg. nginx, certificate > > management, services like CloudFlare and more) > > - The reuse of standard web frameworks and libraries (eg. header parsin= g, > > asynchronous threads) > > - Reducing the diffusion of open source development contribution > > (redefining the same functions in different standards, and different > source > > code is inefficient). > > - Additional features available from current and future web standards > (eg. > > redirect, media-type negotiation, compression, multiplexing, proxying, > > caching, authentication, Header Parsing, URIs, well-named folders, > > Identity, Semantics, etc..) > > - More secure with exactly the same security model as web - (eg. no pla= in > > text email transmission) > > - All security/firewalls leveraging accumulated PORT 80/443 and HTTP > > intelligence. > > > > --- > > > > Appendix 2 > > > > Possible names for this process > > > > - Web Recasting > > - Web Convergence > > - Http Convergence (specifically HTTP of Web Convergence) > > > --=20 -- Todd Hubers --00000000000008ea730579180a02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for = your time. At the very least, I seek validation of the necessity for this f= rom others, while I refine my communication of the ideas I'm trying to = express.

I have been reading a lot of material, an= d also the intro youtube videos. So I do have a good grasp of the correct a= pproach. I understand the fundamental principles of no voting etc., This is= why I was careful to write "collective decision of direction" - = such a direction isn't necessarily conscious/formal. However, It would = have been better if I wrote "..that RFC could be very comprehensive in= cataloguing=C2=A0the reasons why Web Convergence is desirable...".=C2= =A0

I don't expect such a document to be presc= riptive at all. As you say, there is no "decision", although ther= e is an observed "direction" in some IETF proposals and in the in= dustry broadly; this is a tool for decision making and a reference for brev= ity. It would be a body of work that could be referenced, helping to establ= ish why any organisation would write their standard leveraging Web Standard= s (and why not).

https://datatracker.ietf.org/doc/d= raft-ietf-httpbis-bcp56bis/ is a fantastic reference, this is exactly t= he kind of document I was hoping to find. It's a great starting point, = if not the exact thing, I was describing. I'll need to spend time and r= ead it in more detail. It might need to be broadened to "Web"; ei= ther directly or via a separate new Internet Draft. JMAP is a good example = of why such broadening may be useful: The JMAP standard document doesn'= t actually reference HTTP, I believe it's more about JSON schema than H= TTP mechanisms (or perhaps such mechanisms are in other standards that I ha= ven't read yet) - although the charter does mention HTTP - perhaps HTTP= is a missing component from the JMAP standard.

If= I had a fresh stab of a description of a new Internet Draft, it would be &= quot;Choosing whether or not to build new standards upon Web Standards"= ;. The title "Web Convergence" is probably too prescriptive, &quo= t;Building Protocols with Web Standards" might be an appropriate title= , or "Building Standards based on Web Standards".=C2=A0

So with my clarifications above, I would welcome any furthe= r criticisms or support, to help guide me in coming weeks.

Thanks,

Todd

On Fri, 26 Oct 2018 at 12:30, Martin J= . D=C3=BCrst <duerst@it.aoyama= .ac.jp> wrote:
Hello Todd,
This is just a personal opinion, but based on more than 20 years of
experience with various standards organizations including the IETF.

On 2018/10/26 09:57, Todd Hubers wrote:
> Hi All,
>
> Is there a document/RFC about the IETFs collective general movement to= ward
> re-standardisation of things like DNS (DOH), SMTP (JMAP), and maybe ot= hers
> using Web/HTTP/JSON?
>
> I read the introduction of DoH [RFC8484], and noted there was no refer= ence
> there, so such a document probably doesn't exist.

I guess you're right. But there may be documents that are somewhat
related. In particular, I'm thinking of
https://datatracker.ietf.org/doc/draft-= ietf-httpbis-bcp56bis/.

> Instead, it could read something like "Web Convergence is desirab= le
> [RFCXXXX]", and that RFC could be very comprehensive in the colle= ctive
> decision about this direction. It would critically help in determining= when
> a current standard should be considered for Web Convergence.

The IETF is (at least officially) a collection of individuals. Many of
these individuals see trends like the one you bring up here. But the
IETF as a whole isn't organized or empowered to adapt great trends and =
then force everybody to follow them. Where that has been tried, it has
usually not worked extremely well.

Other standards organizations may do more of such "overall direction&q= uot;
documents, but in general, I don't think they have too much success wit= h
them.

> I believe it would be something to be referenced in the charter of suc= h a
> WG, to clarify WHY the work is being completed, in addition to the oth= er
> good reasons. Even if we don't have an RFC, this idea does need a = solid
> name/label.

WGs get formed because enough individuals (and often companies that
employ them) are interested in getting some standardization work done.
That work may be way ahead of a trend, may be in one of the current
trends, may be way behind a trend, or completely unrelated to any trend.
> I have initial ideas for the content of such a Web Convergence RFC
> [Appendix 1], and what it might be ultimately called [Appendix 2]
>
> (I am also new to IETF generally, so I'm still learning. But I lik= e
> learning by doing._

Everybody (including you) can submit an Internet Draft (except this
week). So writing up your ideas and submitting a draft may be a good
idea. My personal advice would be to be more descriptive and less
predictive or prescriptive.

Regards,=C2=A0 =C2=A0Martin.

> Thanks,
>
> Todd Hubers
>
> ---
>
> Appendix 1
>
> For rebuilding of older standards the web way; OR, building new standa= rds
> the web way. The reasons should be the same.
>
> Initial ideas for reasons to be collated in such a document/rfc:
>
> - Accessible directly by web applications (javascript), removing the n= eed
> to push via a specialised application server adaptor service (eg. HTTP= to
> SMTP)
> - The reuse of standard web sysops tools (eg. nginx, certificate
> management, services like CloudFlare and more)
> - The reuse of standard web frameworks and libraries (eg. header parsi= ng,
> asynchronous threads)
> - Reducing the diffusion of open source development contribution
> (redefining the same functions in different standards, and different s= ource
> code is inefficient).
> - Additional features available from current and future web standards = (eg.
> redirect, media-type negotiation, compression, multiplexing, proxying,=
> caching, authentication, Header Parsing, URIs, well-named folders,
> Identity, Semantics, etc..)
> - More secure with exactly the same security model as web - (eg. no pl= ain
> text email transmission)
> - All security/firewalls leveraging accumulated PORT 80/443 and HTTP > intelligence.
>
> ---
>
> Appendix 2
>
> Possible names for this process
>
> - Web Recasting
> - Web Convergence
> - Http Convergence (specifically HTTP of Web Convergence)
>


--
--
Todd Hubers
<= /div>
--00000000000008ea730579180a02--