From nobody Sun Sep 2 17:39:26 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 B26DB130DF0 for ; Sun, 2 Sep 2018 17:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtDLEaAuCYCs for ; Sun, 2 Sep 2018 17:39:22 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4D371124C04 for ; Sun, 2 Sep 2018 17:39:22 -0700 (PDT) Received: from [10.168.3.2] (unknown [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id A2E5B2AEF59; Mon, 3 Sep 2018 03:39:13 +0300 (EEST) To: Neil Jenkins , IETF JMAP Mailing List References: <5e5dfdee-e5ef-5044-a0c1-e1f4804ffe87@dovecot.fi> <1533646198.3653064.1466154280.090B56FE@webmail.messagingengine.com> <37cf4e33-4987-f4ac-b188-b5dbf0dd9b30@dovecot.fi> <5726d51f-be68-470e-8200-a248ba6c97a1@sloti22d1t06> From: Stephan Bosch Message-ID: <30ea0a05-7322-8fe6-b8aa-74ca2162cd69@dovecot.fi> Date: Mon, 3 Sep 2018 02:38:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5726d51f-be68-470e-8200-a248ba6c97a1@sloti22d1t06> Content-Type: multipart/alternative; boundary="------------79A9D6619130BFE9307578C0" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 00:39:25 -0000 This is a multi-part message in MIME format. --------------79A9D6619130BFE9307578C0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Neil, Op 29/08/2018 om 07:22 schreef Neil Jenkins: > Hi Stephan, > >> The thing is, for protocols like IMAP that keep the connection open, >> the solution is simple: kill all active connections from the server >> side, thereby making sure the clients reconnect and (likely) pick up >> on the new settings and capabilities. For JMAP, there's no such >> option: the loss of an HTTP connection from either side is usually >> insignificant. Yes, changed URLs cause visible problems at the >> client, but other session changes (adding accounts, changing >> capabilities) don't lead to problems quickly. If the client never >> re-downloads the session data, it will not pick up on the changes >> indefinitely and the server can do nothing about that. If there is >> some sort of session TTL, the situation will always resolve itself >> within a server-controlled reasonable time frame. > > The trouble with a TTL is always what to set the value to. Too long > and the client can be out of date for a long time; too short and you > have a large number of unnecessary requests. I think a better solution > might be to include a state string on the session object itself, and > have each API request include the current session state on the > Response object. The client can compare them and refetch if different. > This piggybacks onto existing requests so has very little overhead, > but results in almost immediate updates. The only time this wouldn't > work is if e.g. the API url has changed, and so the request fails. But > a failing request probably should prompt the client to refetch the > session object anyway, so you're still covered. > > Sound reasonable? Yes. BTW, what happens if there's some HTTP cache in between? Is that even an acceptable scenario? >>>> The spec already defines an |unsupportedFilter| error, which may be >>>> returned if ”the filter is syntactically valid, but the server >>>> cannot process it“. >>> >>> Given that the filter is generally a result of human input, that >>> seems reasonable. The human can create something less complex.  The >>> general guiding principle of errors is that they should be >>> informative and actionable - the receiver of error should both >>> understand what they did wrong, and have a path to back to success.  >>> The issue with just "unsupportedFilter" could be that it's not easy >>> for the creator to know if it's because it's too complex, or >>> includes an unknown condition. >> >> Bron is stating my point in his last sentence. > > I think this error is the one you want here, but I'll update the > description. If you specified conditions not in the spec, or gave the > wrong type or something, that would be an |invalidArguments| error. > The |unsupportedFilter| error is really "another server may be able to > process this filter but, alas, this one cannot". Clients should then > suggest users simplify their criteria to perhaps find something the > server can support. ok >> I've thought about this a little more. What about turning the >> FilterOperator into an array of conditions in which the first element >> is the operator? So, something like: >> >> "filter": ["AND", {}, {}, ["OR", >> {}, {], ["NOT", ["OR", >> {}, {}, {}]]] > > The trouble with this is that it is difficult to represent in a typed > language. It's not an array of a single type.. It's not even an array > of |(String|FilterCondition)| because the different types are only > allowed to appear in certain positions. But it's not a tuple either > (like the JMAP method calls), because it's variable length. > > I don't think this brings enough benefits to outweigh this pain. Is specification difficulty the only problem here? You could do it in words, much like the methodCalls request field is described in Section 3.2. It just calls it an "Array[]" (which is actually a bit weird given the definitions in Section 1.1) and then specifies what the positions mean. So, something like: A *filter operator* is represented by an array containing two or more elements:       1.  A "String" identifying the operator. This MUST be one of the following strings:           "AND"/"OR"/"NOT":           +  *AND*: all of the conditions must match for the filter to              match.           +  *OR*: at least one of the conditions must match for the              filter to match.           +  *NOT*: none of the conditions must match for the filter to              match.             2.     The remaining elements of the array represent the operator's conditions, each of which is either a nested *filter operation* array or a *FilterCondition* object. The operator in the first element determines how the results from evaluating the conditions against each record are combined into the result of this *filter operator*. Alternatively, you could define a new syntax. Something like: "[ String FilterCondition+ ]" Or whatever. Regards, Stephan. --------------79A9D6619130BFE9307578C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Neil,

Op 29/08/2018 om 07:22 schreef Neil Jenkins:
Hi Stephan,

The thing is, for protocols like IMAP that keep the connection open, the solution is simple: kill all active connections from the server side, thereby making sure the clients reconnect and (likely) pick up on the new settings and capabilities. For JMAP, there's no such option: the loss of an HTTP connection from either side is usually insignificant. Yes, changed URLs cause visible problems at the client, but other session changes (adding accounts, changing capabilities) don't lead to problems quickly. If the client never re-downloads the session data, it will not pick up on the changes indefinitely and the server can do nothing about that. If there is some sort of session TTL, the situation will always resolve itself within a server-controlled reasonable time frame.

The trouble with a TTL is always what to set the value to. Too long and the client can be out of date for a long time; too short and you have a large number of unnecessary requests. I think a better solution might be to include a state string on the session object itself, and have each API request include the current session state on the Response object. The client can compare them and refetch if different. This piggybacks onto existing requests so has very little overhead, but results in almost immediate updates. The only time this wouldn't work is if e.g. the API url has changed, and so the request fails. But a failing request probably should prompt the client to refetch the session object anyway, so you're still covered.

Sound reasonable?

Yes.

BTW, what happens if there's some HTTP cache in between? Is that even an acceptable scenario?

The spec already defines an unsupportedFilter error, which may be returned if ”the filter is syntactically valid, but the server cannot process it“.

Given that the filter is generally a result of human input, that seems reasonable.  The human can create something less complex.  The general guiding principle of errors is that they should be informative and actionable - the receiver of error should both understand what they did wrong, and have a path to back to success.  The issue with just "unsupportedFilter" could be that it's not easy for the creator to know if it's because it's too complex, or includes an unknown condition.

Bron is stating my point in his last sentence.

I think this error is the one you want here, but I'll update the description. If you specified conditions not in the spec, or gave the wrong type or something, that would be an invalidArguments error. The unsupportedFilter error is really "another server may be able to process this filter but, alas, this one cannot". Clients should then suggest users simplify their criteria to perhaps find something the server can support.

ok

I've thought about this a little more. What about turning the FilterOperator into an array of conditions in which the first element is the operator? So, something like:

"filter": ["AND", {<FilterCondition>}, {<FilterCondition>}, ["OR", {<FilterCondition>}, {<FilterCondition>], ["NOT", ["OR", {<FilterCondition>}, {<FilterCondition>}, {<FilterCondition>}]]]

The trouble with this is that it is difficult to represent in a typed language. It's not an array of a single type.. It's not even an array of (String|FilterCondition) because the different types are only allowed to appear in certain positions. But it's not a tuple either (like the JMAP method calls), because it's variable length.

I don't think this brings enough benefits to outweigh this pain.

Is specification difficulty the only problem here? You could do it in words, much like the methodCalls request field is described in Section 3.2. It just calls it an "Array[]" (which is actually a bit weird given the definitions in Section 1.1) and then specifies what the positions mean. So, something like:

A *filter operator* is represented by an array containing two or more elements:

      1.  A "String" identifying the operator. This MUST be one of the following strings:
          "AND"/"OR"/"NOT":

          +  *AND*: all of the conditions must match for the filter to
             match.
          +  *OR*: at least one of the conditions must match for the
             filter to match.
          +  *NOT*: none of the conditions must match for the filter to
             match.
            2.     The remaining elements of the array represent the operator's conditions, each of which is either a nested *filter operation* array or a *FilterCondition* object. The operator in the first element determines how the results from evaluating the conditions against each record are combined into the result of this *filter operator*.

Alternatively, you could define a new syntax. Something like:

"[ String FilterCondition+ ]"

Or whatever.

Regards,

Stephan.
--------------79A9D6619130BFE9307578C0-- From nobody Sun Sep 2 17:43:11 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 47137130DF0 for ; Sun, 2 Sep 2018 17:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vg-YK6m9dYf for ; Sun, 2 Sep 2018 17:43:07 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 257FF124C04 for ; Sun, 2 Sep 2018 17:43:07 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 5BC4C2AEF59; Mon, 3 Sep 2018 03:43:06 +0300 (EEST) To: Neil Jenkins , IETF JMAP Mailing List References: <96560145-ba14-4a49-983b-9d10c6164f71@sloti22d1t06> <1533646736.3656341.1466169560.3D7B259D@webmail.messagingengine.com> <137d905e-7e1b-9b06-edc8-7c9892298bb2@dovecot.fi> <5e611c51-33e3-44b2-ba65-d5845c8e175d@sloti22d1t06> From: Stephan Bosch Message-ID: Date: Mon, 3 Sep 2018 02:42:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5e611c51-33e3-44b2-ba65-d5845c8e175d@sloti22d1t06> Content-Type: multipart/alternative; boundary="------------AFA1F78E598573BC09633C1A" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-mail-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 00:43:09 -0000 This is a multi-part message in MIME format. --------------AFA1F78E598573BC09633C1A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Neil, Op 29/08/2018 om 08:02 schreef Neil Jenkins: > Hi > >> I am mainly concerned about strings that the user will get to see: >> the IDs are not in that realm. I am just saying that a >> specification-enforced limit will hit the multi-byte character >> languages (think e.g. Japanese) more than english. So, while 255 >> octets ought to be enough for everyone, it might not be. I agree 1024 >> is less likely to be too limited, but still: is a capability property >> really such a burden? > > For the reasons explained before I think the limit should be specified > in octets (if clients want to give the user a guaranteed UTF-8 > character limit they can always just divide this by 4…). However, I > guess we can make the actual value of the limit a capability. We > probably want to add: > > * *maxMailboxDepth*: |PositiveInt|null| > The maximum depth of the mailbox hierarchy (i.e. one less than the > maximum number of ancestors a mailbox may have), or |null| for no > limit. > * *maxSizeMailboxName*: |PositiveInt| > The maximum length, in (UTF-8) octets, allowed for the name of a > mailbox. This MUST be >= 255. > Looks good to me. >>> I'm happy with that.  Cyrus' current limitation is purely the length >>> of the internal version of the mailbox name, but you could create >>> A.A.A.A out to MAX_MAILBOX_NAME.  Annoyingly, some buggy clients did >>> that with INBOX.INBOX.INBOX... such that we special-case reject that >>> now. > > Explaining that kind of limit to users is … hard. Renaming folder X > may fail even though the new name is a reasonable length, because the > combined length with some of its descendants could now be too long — > ouch. The server is free to reject the change with an > |invalidProperties| error response though of course, which is fine. I > don't think this should be a capability though. I have no real preference here. Others might.. feel free to pitch in. >>>>> -> How are IMAP namespaces mapped to JMAP? More specifically: how are >>>>> personal and shared mailboxes identified in JMAP? >>>> >>>> They would be presented as different JMAP accounts >>>> the user has access >>>> to. The primary account would (normally) be the one belonging to >>>> the user. >> >> Ok. Then do we need to add a flag that signifies an account as being >> shared/public, so that the client can present mailboxes and other >> objects therein as such? There could e.g. also be an Archive account >> that is still personal, but not primary. > > Hmm, yes that's probably reasonable. I think a simple boolean on each > account object would suffice; something like |"isYours": > true|false| (or |isUser| or |isPersonal|… naming things is hard). > Thoughts on the name? I like isPersonal. Regards, Stephan. --------------AFA1F78E598573BC09633C1A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Neil,


Op 29/08/2018 om 08:02 schreef Neil Jenkins:
Hi

I am mainly concerned about strings that the user will get to see: the IDs are not in that realm. I am just saying that a specification-enforced limit will hit the multi-byte character languages (think e.g. Japanese) more than english. So, while 255 octets ought to be enough for everyone, it might not be. I agree 1024 is less likely to be too limited, but still: is a capability property really such a burden?

For the reasons explained before I think the limit should be specified in octets (if clients want to give the user a guaranteed UTF-8 character limit they can always just divide this by 4…). However, I guess we can make the actual value of the limit a capability. We probably want to add:
  • maxMailboxDepth: PositiveInt|null
    The maximum depth of the mailbox hierarchy (i.e. one less than the maximum number of ancestors a mailbox may have), or null for no limit.
  • maxSizeMailboxName: PositiveInt
    The maximum length, in (UTF-8) octets, allowed for the name of a mailbox. This MUST be >= 255.

Looks good to me.

I'm happy with that.  Cyrus' current limitation is purely the length of the internal version of the mailbox name, but you could create A.A.A.A out to MAX_MAILBOX_NAME.  Annoyingly, some buggy clients did that with INBOX.INBOX.INBOX... such that we special-case reject that now.

Explaining that kind of limit to users is … hard. Renaming folder X may fail even though the new name is a reasonable length, because the combined length with some of its descendants could now be too long — ouch. The server is free to reject the change with an invalidProperties error response though of course, which is fine. I don't think this should be a capability though.

I have no real preference here. Others might.. feel free to pitch in.

-> How are IMAP namespaces mapped to JMAP? More specifically: how are 
personal and shared mailboxes identified in JMAP?

They would be presented as different JMAP accounts the user has access to. The primary account would (normally) be the one belonging to the user.

Ok. Then do we need to add a flag that signifies an account as being shared/public, so that the client can present mailboxes and other objects therein as such? There could e.g. also be an Archive account that is still personal, but not primary.

Hmm, yes that's probably reasonable. I think a simple boolean on each account object would suffice; something like "isYours": true|false (or isUser or isPersonal… naming things is hard). Thoughts on the name?

I like isPersonal.


Regards,

Stephan.
--------------AFA1F78E598573BC09633C1A-- From nobody Mon Sep 3 00:46:35 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 8CFAA130E3A for ; Mon, 3 Sep 2018 00:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=JqH5qF4B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SwdsIICf 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 G1YsVorU5-rG for ; Mon, 3 Sep 2018 00:46:24 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C184130E25 for ; Mon, 3 Sep 2018 00:46:24 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4CC23242; Mon, 3 Sep 2018 03:46:23 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 03 Sep 2018 03:46:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=RXN0BV3R46dYfvp5GpncUrpdQ6UokFfxO9v/3hw6E sk=; b=JqH5qF4B+LdaWRBVvchSB3xALLdg0KgfuE5fnQ7HNI5USOUJoFnTOkmW3 15rTdz1/MUI83/x/YaM1TVY48R+e3zQ/wCozJzFW9XxUP6RCvo3gH5DmI5+r9uPb 3v1H6FkYnSoZWPR9IYhYgECuVclsbmanw+tFq+HMHPufRh6ieX4rFoiT6MGhjyjN jnkgDOdH8iiGMjpq/sZpS5h/mdmuZyGYfVfaBhnx9oE1twdOBb372fNZh7Rafpj4 ZqX/NsM/QjcoMR6z5A0h4IwCS/1IQI7alKsZ6VRfjjO5CXdH6NseWVaZJjEOkUkV 4gsuczA6xmcomWkAbRa6NnrT0O8kw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=RXN0BV3R46dYfvp5GpncUrpdQ6UokFfxO9v/3hw6E sk=; b=SwdsIICf2b9RtBC1Jeg43x1+y5nxaqqG0MLu6XdxrDCtZPdyeDKqjAQ3H zsaMqZ+bQ8iOA+008mw+x96oEMY/Dm2O9msR+rCKUxa7M5NhvMLdbJoUmKypKw0T 9DD1HmvxRTQj4IJ7WZ9DVcHqLbrppc+t/cIrWgMrhLZ6QAPbuLytD085hGTbZLHu IWTuJoFHvOfK6lLUU3wz+97A7L5vtFjorI0MzESSX3o8ghga6lM7Ru2yinjSCiKt 8MLCxc3e8799K0tHi419+r7k6V2xAQ8JOiYmC4je4kd7zf/Mu7OPzamlIP2dmowY 41jSN/xLZE2qIPWkmHaP5VfNZhYKQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 60CD3E4E5; Mon, 3 Sep 2018 03:46:22 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.5-402-ged1dc7a-fmnext-20180831v1 x-jmap-identity-id: 64588216 In-Reply-To: <30ea0a05-7322-8fe6-b8aa-74ca2162cd69@dovecot.fi> References: <5e5dfdee-e5ef-5044-a0c1-e1f4804ffe87@dovecot.fi> <1533646198.3653064.1466154280.090B56FE@webmail.messagingengine.com> <37cf4e33-4987-f4ac-b188-b5dbf0dd9b30@dovecot.fi> <5726d51f-be68-470e-8200-a248ba6c97a1@sloti22d1t06> <30ea0a05-7322-8fe6-b8aa-74ca2162cd69@dovecot.fi> Date: Mon, 03 Sep 2018 03:46:21 -0400 From: Neil Jenkins To: IETF JMAP Mailing List , Stephan Bosch Content-Type: multipart/alternative; boundary=f2a8cef3c74145d498dbe9c5217b3ac7 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 07:46:33 -0000 --f2a8cef3c74145d498dbe9c5217b3ac7 Content-Type: text/plain On Mon, 3 Sep 2018, at 10:39 AM, Stephan Bosch wrote: > BTW, what happens if there's some HTTP cache in between? Is that even an acceptable scenario? Yes, standard HTTP semantics apply, so the server needs to make sure it sets appropriate cache control headers on the response. >>> I've thought about this a little more. What about turning the FilterOperator into an array of conditions in which the first element is the operator? So, something like: >>> >>> "filter": ["AND", {}, {}, ["OR", {}, {], ["NOT", ["OR", {}, {}, {}]]] >> >> The trouble with this is that it is difficult to represent in a typed language. It's not an array of a single type.. It's not even an array of `(String|FilterCondition)` because the different types are only allowed to appear in certain positions. But it's not a tuple either (like the JMAP method calls), because it's variable length. >> >> I don't think this brings enough benefits to outweigh this pain. > > Is specification difficulty the only problem here? If it's difficult to specify it's also likely to be difficult to implement in strongly typed languages. I just don't see this syntactical change bringing many benefits, and it seems likely to have definite implementation difficulty downsides. > Section 3.2. It just calls it an "Array[]" (which is actually a bit weird given the definitions in Section 1.1) Yes, it is a bit weird, I'll rewrite that. Neil. --f2a8cef3c74145d498dbe9c5217b3ac7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, 3 = Sep 2018, at 10:39 AM, Stephan Bosch wrote:

BTW, what happens if there's some HTTP= cache in between? Is that even an acceptable scenario?


Yes, standard HTTP semantics apply, so the server needs to make sure i= t sets appropriate cache control headers on the response.
= I've thought about this a little more. What about turning the FilterOperator into an array of conditions in which the first element is the operator? So, something like:

"filter": ["AND", {<FilterCondition>}, {<FilterCondition>}, ["OR", {<FilterCondition>}, {<FilterCondition>], ["NOT", ["OR", {<FilterCondition>}, {<FilterCondition>}, {<FilterCondition>}]]]

The trouble with this is that it is difficult to represent in a typed language. It's not an array of a single type.. It's not even an array of (String|FilterCondition) because the di= fferent types are only allowed to appear in certain positions. But it's not a tuple either (like the JMAP method calls), because it's variable length.

<= /div>
I don't think this brings enough benefits to outweigh this pain.

Is specification= difficulty the only problem here?

=
If it's difficult to specify it's also likely to be difficult to im= plement in strongly typed languages. I just don't see this syntactical c= hange bringing many benefits, and it seems likely to have definite imple= mentation difficulty downsides.

Section 3.2. It just calls it= an "Array[]" (which is actually a bit weird given the definitions in Section 1.1)

Yes, it is a bit weird, I'll rewrite that.
<= br>
Neil.
--f2a8cef3c74145d498dbe9c5217b3ac7-- From nobody Mon Sep 3 01:52:30 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 C51991252B7 for ; Mon, 3 Sep 2018 01:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC3DeLlPdZFH for ; Mon, 3 Sep 2018 01:52:27 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 31CB5130DE2 for ; Mon, 3 Sep 2018 01:52:27 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id 1E7A128D0E1; Mon, 3 Sep 2018 11:52:16 +0300 (EEST) To: Neil Jenkins , IETF JMAP Mailing List References: <5e5dfdee-e5ef-5044-a0c1-e1f4804ffe87@dovecot.fi> <1533646198.3653064.1466154280.090B56FE@webmail.messagingengine.com> <37cf4e33-4987-f4ac-b188-b5dbf0dd9b30@dovecot.fi> <5726d51f-be68-470e-8200-a248ba6c97a1@sloti22d1t06> <30ea0a05-7322-8fe6-b8aa-74ca2162cd69@dovecot.fi> From: Stephan Bosch Message-ID: <5f090839-deea-b290-bf8d-956ba5cf32ae@dovecot.fi> Date: Mon, 3 Sep 2018 10:51:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2669CA45336DF1C56DC9B030" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 08:52:29 -0000 This is a multi-part message in MIME format. --------------2669CA45336DF1C56DC9B030 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Neil, Op 03/09/2018 om 09:46 schreef Neil Jenkins: > On Mon, 3 Sep 2018, at 10:39 AM, Stephan Bosch wrote: >> >> BTW, what happens if there's some HTTP cache in between? Is that even >> an acceptable scenario? >> > > Yes, standard HTTP semantics apply, so the server needs to make sure > it sets appropriate cache control headers on the response. So, what is appropriate? No-cache, no-store? Since otherwise there's still some TTL (age) value to consider. >>>> I've thought about this a little more. What about turning the >>>> FilterOperator into an array of conditions in which the first >>>> element is the operator? So, something like: >>>> >>>> "filter": ["AND", {}, {}, ["OR", >>>> {}, {], ["NOT", ["OR", >>>> {}, {}, {}]]] >>> >>> The trouble with this is that it is difficult to represent in a >>> typed language. It's not an array of a single type.. It's not even >>> an array of |(String|FilterCondition)| because the different types >>> are only allowed to appear in certain positions. But it's not a >>> tuple either (like the JMAP method calls), because it's variable length. >>> >>> I don't think this brings enough benefits to outweigh this pain. >> >> Is specification difficulty the only problem here? > > If it's difficult to specify it's also likely to be difficult to > implement in strongly typed languages. I just don't see this > syntactical change bringing many benefits, and it seems likely to have > definite implementation difficulty downsides. Oh, I see what you mean now by strongly typed languages. That can be a valid concern. Regards, Stephan. --------------2669CA45336DF1C56DC9B030 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Neil,


Op 03/09/2018 om 09:46 schreef Neil Jenkins:
On Mon, 3 Sep 2018, at 10:39 AM, Stephan Bosch wrote:

BTW, what happens if there's some HTTP cache in between? Is that even an acceptable scenario?


Yes, standard HTTP semantics apply, so the server needs to make sure it sets appropriate cache control headers on the response.

So, what is appropriate? No-cache, no-store? Since otherwise there's still some TTL (age) value to consider.

I've thought about this a little more. What about turning the FilterOperator into an array of conditions in which the first element is the operator? So, something like:

"filter": ["AND", {<FilterCondition>}, {<FilterCondition>}, ["OR", {<FilterCondition>}, {<FilterCondition>], ["NOT", ["OR", {<FilterCondition>}, {<FilterCondition>}, {<FilterCondition>}]]]

The trouble with this is that it is difficult to represent in a typed language. It's not an array of a single type.. It's not even an array of (String|FilterCondition) because the different types are only allowed to appear in certain positions. But it's not a tuple either (like the JMAP method calls), because it's variable length.

I don't think this brings enough benefits to outweigh this pain.

Is specification difficulty the only problem here?

If it's difficult to specify it's also likely to be difficult to implement in strongly typed languages. I just don't see this syntactical change bringing many benefits, and it seems likely to have definite implementation difficulty downsides.

Oh, I see what you mean now by strongly typed languages. That can be a valid concern.

Regards,

Stephan.
--------------2669CA45336DF1C56DC9B030-- From nobody Mon Sep 3 04:37: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 C34C6130E3F for ; Mon, 3 Sep 2018 04:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n61OIpouYNi for ; Mon, 3 Sep 2018 04:37:16 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 43400130E3E for ; Mon, 3 Sep 2018 04:37:16 -0700 (PDT) Received: from [10.217.110.125] (officegw.dovecot.fi [193.209.119.1]) by mail.dovecot.fi (Postfix) with ESMTPSA id 79CB128D0E1; Mon, 3 Sep 2018 14:27:31 +0300 (EEST) To: Stephan Bosch , Neil Jenkins , IETF JMAP Mailing List References: <5e5dfdee-e5ef-5044-a0c1-e1f4804ffe87@dovecot.fi> <1533646198.3653064.1466154280.090B56FE@webmail.messagingengine.com> <37cf4e33-4987-f4ac-b188-b5dbf0dd9b30@dovecot.fi> <5726d51f-be68-470e-8200-a248ba6c97a1@sloti22d1t06> <30ea0a05-7322-8fe6-b8aa-74ca2162cd69@dovecot.fi> <5f090839-deea-b290-bf8d-956ba5cf32ae@dovecot.fi> From: Aki Tuomi Openpgp: preference=signencrypt Autocrypt: addr=aki.tuomi@dovecot.fi; prefer-encrypt=mutual; keydata= xsBNBFb7bukBCACpK7GFwH/gyL0oF8t91WM7S+UjuQ1vOQZg2eoCUHi4ILpm1Kae4UeZLB2X Vbeph+k29BIQbo+Hjv6rq6JzPfKIZCRLLrkMD1MtA0YB7ZYiACywLrATAdAMJ6sRq+DL5Rlr A2CvviTifz6DwEnbqI+ckcKggsY2gywHs5muDw+n5TwLiL0V9IU478vg7OUWzMZ42toTmeTW 2MtsIAE5xbnjZ58LUSZR2CNO8SAtDHYI558ACkS0wHBAoRFNv27IPr3cebiPsIglSEIBr0R1 F1Twbgm6mWVBhK+smDgGxmmuAhH6boSaKWoWAq+tNf+6oXnr3/D0IPtR8c/bZobtvWG3ABEB AAHNJ1R1b21pLCBBa2kgPGFraS50dW9taUBvcGVuLXhjaGFuZ2UuY29tPsLAfgQTAQIAKAIb AwUJEswDAAUCW2P/aAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQGTtjY7NEQgYmMwf9 G5U0+vKJB+f3Vl8rjPqlXmUZu4waf6pig5lLCrgu56ZkqEDmjaxmxXAah7JZ6dD/66kzlQzK QPYpLor0KnTZgm8XZr+MtqLK8DMF/4+iljADvkS4nfJuX3LbdafPyuk4x+GIa+6NJ+y34jZ2 84Oesj+FtPOevthR9rDmnc2KQjBD30ceKsadxIKqWPYPqPESQ0PyMu9tOaWNdGntx8LvO3Ll spZ2DzEh5rregFKtO01jR9ai5r3mbUrQqwzWLxJztBYjds8D5VAiCBeivUxetDqhoPr3CyKH Stc5GfgHvazjG34H+CShReqIylfR4mwc654qkmVQfPMMUTaa677n8c7ATQRW+27pAQgAosZd RB8tui65tjna4iYKPHqcNDZUXOUuPLTucYc2tY2v67POGr44gOZNzuQWKyXRSBs+Q2zJHcbc cPe0ZEptkOCOwdhhvBwZLKa6nI9jnJ0K+szT2NbD0YkvaIDALA9pVGMJqa88wvkkocf/I5fk dTk6xuLp8AamRXvcPZuUPo/s2PXQV4u+gtKdX1FmaHiBg1oQhtoDWZO04H74r9fyPPs499ra 9iNckSlZP51OUFBbV/RmbtEC031r4iXUAgiL0nQ1mNpRIW+PU/5beX/4YwYeCpzy7g0XfMaJ oMWDamRdXgzkXK6IJIxwo/89M8qPW+Bkh88yAennI2SsEvniXQARAQABwsBxBBgBAgAbBQJW +27pAhsMBAsJCAcGFQoJCAsCBQkSzAMAAAoJEBk7Y2OzREIGCm8IAIZkj5FClx8EmPy1caC+ CNv1mVrC2YhKY9Zh255JUtt+Xp6tshN6IOr+saNkcwgUghxmx6+asZXPDHTqhXoswPi28k1u CY7n4gvh3jlS7a0HeI0sy2RCsrkIaQD2uSt+ju9fpEM2aOXQHGT/x6gZhJ7Uwu+JfDnCB7CB FjVnRaV2/87Y0ZImfhIMPYRzwOyWW6KR+JPIutyZAWo9c7mmjKbySLXhqgZariMJU+RQF5/d aQsiRJKP1IkC/Ncy/iZSnGvPIRZjvQxtrz+4xexZX6NjG7IbKAwmbo1t27cF3hE4HejakF5b LOhznVWubhjXp1J6pL9fymHmG2tZPsgwXcA= Organization: Dovecot Oy Message-ID: <8e4ac10b-06fc-ab5e-7d37-56666aa9e9b8@dovecot.fi> Date: Mon, 3 Sep 2018 14:27:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5f090839-deea-b290-bf8d-956ba5cf32ae@dovecot.fi> Content-Type: multipart/alternative; boundary="------------4B5018DF751397A0ECD54844" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 11:37:18 -0000 This is a multi-part message in MIME format. --------------4B5018DF751397A0ECD54844 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03.09.2018 11:51, Stephan Bosch wrote: > > Hi Neil, > > > Op 03/09/2018 om 09:46 schreef Neil Jenkins: >> On Mon, 3 Sep 2018, at 10:39 AM, Stephan Bosch wrote: >>> >>> BTW, what happens if there's some HTTP cache in between? Is that >>> even an acceptable scenario? >>> >> >> Yes, standard HTTP semantics apply, so the server needs to make sure >> it sets appropriate cache control headers on the response. > > So, what is appropriate? No-cache, no-store? Since otherwise there's > still some TTL (age) value to consider. > I guess it depends on the object, for mail objects you can probably use quite large expiry time, and for things like session-data you can set must-revalidate? Perhaps some considerations on how these headers should be set could be added to the RFC, as there is clearly no single suitable value. Aki --------------4B5018DF751397A0ECD54844 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 03.09.2018 11:51, Stephan Bosch wrote:

Hi Neil,


Op 03/09/2018 om 09:46 schreef Neil Jenkins:
On Mon, 3 Sep 2018, at 10:39 AM, Stephan Bosch wrote:

BTW, what happens if there's some HTTP cache in between? Is that even an acceptable scenario?


Yes, standard HTTP semantics apply, so the server needs to make sure it sets appropriate cache control headers on the response.

So, what is appropriate? No-cache, no-store? Since otherwise there's still some TTL (age) value to consider.

I guess it depends on the object, for mail objects you can probably use quite large expiry time, and for things like session-data you can set must-revalidate?

Perhaps some considerations on how these headers should be set could be added to the RFC, as there is clearly no single suitable value.

Aki
--------------4B5018DF751397A0ECD54844-- From nobody Mon Sep 3 21:02:07 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 82CC0130E02 for ; Mon, 3 Sep 2018 21:02:05 -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, STYLE_GIBBERISH=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=WDUt9FHq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BNjqrDPU 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 DgtSos9Kyif4 for ; Mon, 3 Sep 2018 21:02:04 -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 50E99128CB7 for ; Mon, 3 Sep 2018 21:02:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DBC8F21DFB; Tue, 4 Sep 2018 00:02:02 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Tue, 04 Sep 2018 00:02:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ToY8GGLJzbNiciC303fA23Jhv/zAaAmFqqr4YLiPM io=; b=WDUt9FHqA13wSn69j3MIJEjPzlt2Xd6CJ8pcW64SqOpZ/jXrlyLkUqkBw YsDLy0x6uPJjbrsdRI7mAPqrruH0cdTqGH9ybZRnYEzunvyQZMuzuCr94gEPBduX F/hmmoWQIxigW7NQyOFz/jFhco0fHx+okXMyxXmbYOLSPjbQoQ0Lm6UXjIrEw9uu BiMxgcNzlkHZFLa96f4wfuSUn8k2PnFwUOAi7bBIIZV8gyu7ASvusU5VBa+RCTl4 y0ZOOTk59j86qHmWyLFoO9Sm/ferNzAEy7I7Ci2DOk2P36xmnFw8W3SFR72mXNIC GMXmF4HJFn/Hjdphn0ykzxksT/Nog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ToY8GGLJzbNiciC303fA23Jhv/zAaAmFqqr4YLiPM io=; b=BNjqrDPUd9UI96ESISSURlf6TcAeMhtkh0tsgn+MQFG3RhckHgynUZxvL cPhBFBQ0O60l48hjVVOJC/yHmMP6bOgjSh6hTZIrqVDQsdeAF4SR5WwBsoZiR6Gl kibvR6oQXCmoIemKOBL/DpvbKGh97EdPkGFHQOw6oGt6ovLzMNR4BShSN4GPcwhU xPvMUrItvHbGvGDNma+2ZGGKp4ZfdUMKpIOpBqRvpnreydTW2GIGxRUVnqG8NMlb /MYt83c00e+SskUP0ozGlDCTRQbWK9Fp0vO4NX99BzSzA9zA9FxLLxOfGo0dIVX6 kOuXHsdH7ddE6w+KTi40jhfVe+f9g== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 23B40E299; Tue, 4 Sep 2018 00:02:02 -0400 (EDT) Message-Id: <094d0f2f-0640-47b1-9109-f7522b8d64be@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-402-ged1dc7a-fmnext-20180831v1 x-jmap-identity-id: 64588216 In-Reply-To: <8e4ac10b-06fc-ab5e-7d37-56666aa9e9b8@dovecot.fi> References: <5e5dfdee-e5ef-5044-a0c1-e1f4804ffe87@dovecot.fi> <1533646198.3653064.1466154280.090B56FE@webmail.messagingengine.com> <37cf4e33-4987-f4ac-b188-b5dbf0dd9b30@dovecot.fi> <5726d51f-be68-470e-8200-a248ba6c97a1@sloti22d1t06> <30ea0a05-7322-8fe6-b8aa-74ca2162cd69@dovecot.fi> <5f090839-deea-b290-bf8d-956ba5cf32ae@dovecot.fi> <8e4ac10b-06fc-ab5e-7d37-56666aa9e9b8@dovecot.fi> Date: Tue, 04 Sep 2018 00:02:01 -0400 From: Neil Jenkins To: Stephan Bosch , IETF JMAP Mailing List , Aki Tuomi Content-Type: multipart/alternative; boundary=249a6c58e59d4b6f820eec9fd9ee0bce Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 04:02:05 -0000 --249a6c58e59d4b6f820eec9fd9ee0bce Content-Type: text/plain On Mon, 3 Sep 2018, at 9:27 PM, Aki Tuomi wrote: > I guess it depends on the object, for mail objects you can probably use quite large expiry time, and for things like session-data you can set must-revalidate? If you are downloading a blob (e.g. a raw message), I would expect a very long cache time as blobIds are immutable so the contents cannot change for the URL, so something like `Cache-Control: private, max-age=31536000`. For your session object, `Cache-Control: no-cache, no-store, must-revalidate` probably makes sense. I don't know whether this really needs a comment in the spec; it already says standard HTTP semantics are presumed. Neil. --249a6c58e59d4b6f820eec9fd9ee0bce Content-Type: text/html
On Mon, 3 Sep 2018, at 9:27 PM, Aki Tuomi wrote:
I guess it depends on the object, for mail objects you can probably use quite large expiry time, and for things like session-data you can set must-revalidate?

If you are downloading a blob (e.g. a raw message), I would expect a very long cache time as blobIds are immutable so the contents cannot change for the URL, so something like Cache-Control: private, max-age=31536000. For your session object, Cache-Control: no-cache, no-store, must-revalidate probably makes sense.

I don't know whether this really needs a comment in the spec; it already says standard HTTP semantics are presumed.

Neil.
--249a6c58e59d4b6f820eec9fd9ee0bce-- From nobody Mon Sep 3 22:55:45 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 A9FC3130DE9 for ; Mon, 3 Sep 2018 22:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, STYLE_GIBBERISH=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 H262FyQweVN9 for ; Mon, 3 Sep 2018 22:55:42 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id DF331130DD5 for ; Mon, 3 Sep 2018 22:55:41 -0700 (PDT) Received: from [10.217.110.125] (officegw.dovecot.fi [193.209.119.1]) by mail.dovecot.fi (Postfix) with ESMTPSA id 41EC02A6901; Tue, 4 Sep 2018 08:55:36 +0300 (EEST) To: Neil Jenkins , Stephan Bosch , IETF JMAP Mailing List References: <5e5dfdee-e5ef-5044-a0c1-e1f4804ffe87@dovecot.fi> <1533646198.3653064.1466154280.090B56FE@webmail.messagingengine.com> <37cf4e33-4987-f4ac-b188-b5dbf0dd9b30@dovecot.fi> <5726d51f-be68-470e-8200-a248ba6c97a1@sloti22d1t06> <30ea0a05-7322-8fe6-b8aa-74ca2162cd69@dovecot.fi> <5f090839-deea-b290-bf8d-956ba5cf32ae@dovecot.fi> <8e4ac10b-06fc-ab5e-7d37-56666aa9e9b8@dovecot.fi> <094d0f2f-0640-47b1-9109-f7522b8d64be@sloti22d1t06> From: Aki Tuomi Openpgp: preference=signencrypt Autocrypt: addr=aki.tuomi@dovecot.fi; prefer-encrypt=mutual; keydata= xsBNBFb7bukBCACpK7GFwH/gyL0oF8t91WM7S+UjuQ1vOQZg2eoCUHi4ILpm1Kae4UeZLB2X Vbeph+k29BIQbo+Hjv6rq6JzPfKIZCRLLrkMD1MtA0YB7ZYiACywLrATAdAMJ6sRq+DL5Rlr A2CvviTifz6DwEnbqI+ckcKggsY2gywHs5muDw+n5TwLiL0V9IU478vg7OUWzMZ42toTmeTW 2MtsIAE5xbnjZ58LUSZR2CNO8SAtDHYI558ACkS0wHBAoRFNv27IPr3cebiPsIglSEIBr0R1 F1Twbgm6mWVBhK+smDgGxmmuAhH6boSaKWoWAq+tNf+6oXnr3/D0IPtR8c/bZobtvWG3ABEB AAHNJ1R1b21pLCBBa2kgPGFraS50dW9taUBvcGVuLXhjaGFuZ2UuY29tPsLAfgQTAQIAKAIb AwUJEswDAAUCW2P/aAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQGTtjY7NEQgYmMwf9 G5U0+vKJB+f3Vl8rjPqlXmUZu4waf6pig5lLCrgu56ZkqEDmjaxmxXAah7JZ6dD/66kzlQzK QPYpLor0KnTZgm8XZr+MtqLK8DMF/4+iljADvkS4nfJuX3LbdafPyuk4x+GIa+6NJ+y34jZ2 84Oesj+FtPOevthR9rDmnc2KQjBD30ceKsadxIKqWPYPqPESQ0PyMu9tOaWNdGntx8LvO3Ll spZ2DzEh5rregFKtO01jR9ai5r3mbUrQqwzWLxJztBYjds8D5VAiCBeivUxetDqhoPr3CyKH Stc5GfgHvazjG34H+CShReqIylfR4mwc654qkmVQfPMMUTaa677n8c7ATQRW+27pAQgAosZd RB8tui65tjna4iYKPHqcNDZUXOUuPLTucYc2tY2v67POGr44gOZNzuQWKyXRSBs+Q2zJHcbc cPe0ZEptkOCOwdhhvBwZLKa6nI9jnJ0K+szT2NbD0YkvaIDALA9pVGMJqa88wvkkocf/I5fk dTk6xuLp8AamRXvcPZuUPo/s2PXQV4u+gtKdX1FmaHiBg1oQhtoDWZO04H74r9fyPPs499ra 9iNckSlZP51OUFBbV/RmbtEC031r4iXUAgiL0nQ1mNpRIW+PU/5beX/4YwYeCpzy7g0XfMaJ oMWDamRdXgzkXK6IJIxwo/89M8qPW+Bkh88yAennI2SsEvniXQARAQABwsBxBBgBAgAbBQJW +27pAhsMBAsJCAcGFQoJCAsCBQkSzAMAAAoJEBk7Y2OzREIGCm8IAIZkj5FClx8EmPy1caC+ CNv1mVrC2YhKY9Zh255JUtt+Xp6tshN6IOr+saNkcwgUghxmx6+asZXPDHTqhXoswPi28k1u CY7n4gvh3jlS7a0HeI0sy2RCsrkIaQD2uSt+ju9fpEM2aOXQHGT/x6gZhJ7Uwu+JfDnCB7CB FjVnRaV2/87Y0ZImfhIMPYRzwOyWW6KR+JPIutyZAWo9c7mmjKbySLXhqgZariMJU+RQF5/d aQsiRJKP1IkC/Ncy/iZSnGvPIRZjvQxtrz+4xexZX6NjG7IbKAwmbo1t27cF3hE4HejakF5b LOhznVWubhjXp1J6pL9fymHmG2tZPsgwXcA= Organization: Dovecot Oy Message-ID: <37993371-d16f-0f94-1a46-db66c29b7eb4@dovecot.fi> Date: Tue, 4 Sep 2018 08:55:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <094d0f2f-0640-47b1-9109-f7522b8d64be@sloti22d1t06> Content-Type: multipart/alternative; boundary="------------03CE4874CB092D5317AFC6DA" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 05:55:44 -0000 This is a multi-part message in MIME format. --------------03CE4874CB092D5317AFC6DA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 04.09.2018 07:02, Neil Jenkins wrote: > On Mon, 3 Sep 2018, at 9:27 PM, Aki Tuomi wrote: >> I guess it depends on the object, for mail objects you can probably >> use quite large expiry time, and for things like session-data you can >> set must-revalidate? > > If you are downloading a blob (e.g. a raw message), I would expect a > very long cache time as blobIds are immutable so the contents cannot > change for the URL, so something like |Cache-Control: private, > max-age=31536000|. For your session object, |Cache-Control: no-cache, > no-store, must-revalidate| probably makes sense. > > I don't know whether this really needs a comment in the spec; it > already says standard HTTP semantics are presumed. > > Neil. > I don't know. Standard HTTP semantics cannot really make any claims over application specific data. Already those two statements should be in the RFC, telling which bits you can and can't cache, and how long. Otherwise we might end up having implementations that do not set any cache control headers, or set them in confusing ways, and then they go thru some proxy that sets a cache on anything that doesn't. Telling *how* to set the cache values is not within scope of this RFC, I agree. But telling which objects should be and for how long should be included at least as considerations for implementers? Aki --------------03CE4874CB092D5317AFC6DA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 04.09.2018 07:02, Neil Jenkins wrote:
On Mon, 3 Sep 2018, at 9:27 PM, Aki Tuomi wrote:
I guess it depends on the object, for mail objects you can probably use quite large expiry time, and for things like session-data you can set must-revalidate?

If you are downloading a blob (e.g. a raw message), I would expect a very long cache time as blobIds are immutable so the contents cannot change for the URL, so something like Cache-Control: private, max-age=31536000. For your session object, Cache-Control: no-cache, no-store, must-revalidate probably makes sense.

I don't know whether this really needs a comment in the spec; it already says standard HTTP semantics are presumed.

Neil.


I don't know. Standard HTTP semantics cannot really make any claims over application specific data. Already those two statements should be in the RFC, telling which bits you can and can't cache, and how long. Otherwise we might end up having implementations that do not set any cache control headers, or set them in confusing ways, and then they go thru some proxy that sets a cache on anything that doesn't.

Telling *how* to set the cache values is not within scope of this RFC, I agree. But telling which objects should be and for how long should be included at least as considerations for implementers?

Aki
--------------03CE4874CB092D5317AFC6DA-- From nobody Tue Sep 4 02:09:05 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 2C119130E60 for ; Tue, 4 Sep 2018 02:09:04 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, STYLE_GIBBERISH=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 C66zwYBRRQWM for ; Tue, 4 Sep 2018 02:09:01 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 03A9E130E18 for ; Tue, 4 Sep 2018 02:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1536052140; d=isode.com; s=june2016; i=@isode.com; bh=3sfihWllvH1sUOk4X4rQF/OUuwvCXlF626sFn8E13WM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=OgtUWso/M1q4m+BmoLOurE/bop88HCKb9qn4MRNShj7Ab9nehtI64tt+atLSoC41A4yFsO Xc/sbPc5NzOlgRAsoXArNwdBPZsu4dm+f8yMc7YlpGLNbObiNXMiQwURu0YMOhj1QsJ2IK vyArIrV34mFJneCke5ZQ7vMIeyqCivE=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 4 Sep 2018 10:09:00 +0100 To: Aki Tuomi , Neil Jenkins References: <5e5dfdee-e5ef-5044-a0c1-e1f4804ffe87@dovecot.fi> <1533646198.3653064.1466154280.090B56FE@webmail.messagingengine.com> <37cf4e33-4987-f4ac-b188-b5dbf0dd9b30@dovecot.fi> <5726d51f-be68-470e-8200-a248ba6c97a1@sloti22d1t06> <30ea0a05-7322-8fe6-b8aa-74ca2162cd69@dovecot.fi> <5f090839-deea-b290-bf8d-956ba5cf32ae@dovecot.fi> <8e4ac10b-06fc-ab5e-7d37-56666aa9e9b8@dovecot.fi> <094d0f2f-0640-47b1-9109-f7522b8d64be@sloti22d1t06> <37993371-d16f-0f94-1a46-db66c29b7eb4@dovecot.fi> Cc: IETF JMAP Mailing List From: Alexey Melnikov Message-ID: <3a2bfcc3-5e89-a35f-6f19-c08183c471cb@isode.com> Date: Tue, 4 Sep 2018 10:08:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <37993371-d16f-0f94-1a46-db66c29b7eb4@dovecot.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0C614AEB6742624AE4EABBA0" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 09:09:04 -0000 --------------0C614AEB6742624AE4EABBA0 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 04/09/2018 06:55, Aki Tuomi wrote: > On 04.09.2018 07:02, Neil Jenkins wrote: > >> On Mon, 3 Sep 2018, at 9:27 PM, Aki Tuomi wrote: >>> I guess it depends on the object, for mail objects you can probably=20 >>> use quite large expiry time, and for things like session-data you=20 >>> can set must-revalidate? >> >> If you are downloading a blob (e.g. a raw message), I would expect a=20 >> very long cache time as blobIds are immutable so the contents cannot=20 >> change for the URL, so something like |Cache-Control: private,=20 >> max-age=3D31536000|. For your session object, |Cache-Control:=C2=A0no-cac= he,=20 >> no-store, must-revalidate|=C2=A0probably makes sense. >> >> I don't know whether this really needs a comment in the spec; it=20 >> already says standard HTTP semantics are presumed. >> >> Neil. >> > > I don't know. Standard HTTP semantics cannot really make any claims=20 > over application specific data. Already those two statements should be=20 > in the RFC, telling which bits you can and can't cache, and how long.=20 > Otherwise we might end up having implementations that do not set any=20 > cache control headers, or set them in confusing ways, and then they go=20 > thru some proxy that sets a cache on anything that doesn't. > > Telling *how* to set the cache values is not within scope of this RFC,=20 > I agree. But telling which objects should be and for how long should=20 > be included at least as considerations for implementers? I tend to agree. Implementors advice (even if it is informative) would=20 be good in regards to caching. --------------0C614AEB6742624AE4EABBA0 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 04/09/2018 06:55, Aki Tuomi wrote:

On 04.09.2018 07:02, Neil Jenkins wrote:

On Mon, 3 Sep 2018, at 9:27 PM, Aki Tuomi wrote:
I guess it depends on the object, for mail objects you can probably use quite large expiry time, and for things like session-data you can set must-revalidate?

If you are downloading a blob (e.g. a raw message), I would expect a very long cache time as blobIds are immutable so the contents cannot change for the URL, so something like Cache-Control: private, max-age=3D31536000. For your session object, Cache-Control:=C2=A0no-cache, no-store, must-revalidate=C2=A0probably makes sense.

I don't know whether this really needs a comment in the spec; it already says standard HTTP semantics are presumed.

Neil.


I don't know. Standard HTTP semantics cannot really make any claims over application specific data. Already those two statements should be in the RFC, telling which bits you can and can't cache, and how long. Otherwise we might end up having implementations that do not set any cache control headers, or set them in confusing ways, and then they go thru some proxy that sets a cache on anything that doesn't.

Telling *how* to set the cache values is not within scope of this RFC, I agree. But telling which objects should be and for how long should be included at least as considerations for implementers?

I tend to agree. Implementors advice (even if it is informative) would be good in regards to caching.

--------------0C614AEB6742624AE4EABBA0-- From nobody Wed Sep 5 00:42:11 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 82DFB130DC5 for ; Wed, 5 Sep 2018 00:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.516 X-Spam-Level: * X-Spam-Status: No, score=1.516 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, STYLE_GIBBERISH=3.499] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=N6mwJOCT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e4dA/r0M 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 omyfh3MtdSOJ for ; Wed, 5 Sep 2018 00:42:07 -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 0E023130DE1 for ; Wed, 5 Sep 2018 00:42:07 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EC67221E06; Wed, 5 Sep 2018 03:42:04 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Wed, 05 Sep 2018 03:42:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=SkI1k0omvo2/kvxu2Dt6enNcNoP3ZCvNwoQwQerb8 Dg=; b=N6mwJOCTjJNQWYEGM/MlQFdCxQnfRNFIJ1D6/Od3PGnnNtEuxOgXmeyLI dyJDih1T0ZJeQR+/SUd+16oIikjdzRH4HRSqYRTjzUBQx5A7Gck4OCRSjxZa+7qW CYy/TiTcJhcv957i0YerGBwdRQVZpYICzPN7PZGxaiT7McVR/UBAApGk1dutQiRR NUaqVH79S8AJek1Gq3E+qJhsxOvcW8O8OYnv0gBo3yelNCuf/ElaN+1TCYipqVr2 g5cBChLfaHGWV46kbPlPOcQEwTRv+KAOSYSuaFg+FYedaj/99/bhIgWyOeVDJ6Tc hMaMg9uVop+zh9rUMxbGx4XazKuqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=SkI1k0omvo2/kvxu2Dt6enNcNoP3ZCvNwoQwQerb8 Dg=; b=e4dA/r0MaGC2Rz8NdYQI3Ua243OI6+fZn4KzptqBUHMGl0CK/aurSmkwk ESLU3DcUCrwJYdBa7ojKJ02jbhxc1E5Bt7Wc24efXU2O2fG26kXdBQJS57YTRlh9 blJlAmWKgjiQ8L4Hri3hcAloR6ks5vVi1exQT95w5osn6XfD3qlCBxdLsgrUvnPt FM+j45kXozt060kYijtBqh6bgnWo3j0cuk1ZQVAti61HhtRqzT/4LQSIv2rXM0Mv Q15ZGpQRzl0HBstEzFjDSjY3/sEwCldLRv2aIqUCdMAznfGG8eK86OZOt4v5fQhR oFV92M6gQb07wRMMe0c9CoSXC5l7w== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2BD1FE54D; Wed, 5 Sep 2018 03:42:03 -0400 (EDT) Message-Id: <1f03b2f6-b3e9-4331-b013-424058159b1b@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-429-gbfba35b-fmstable-20180905v1 x-jmap-identity-id: 64588216 In-Reply-To: <3a2bfcc3-5e89-a35f-6f19-c08183c471cb@isode.com> References: <5e5dfdee-e5ef-5044-a0c1-e1f4804ffe87@dovecot.fi> <1533646198.3653064.1466154280.090B56FE@webmail.messagingengine.com> <37cf4e33-4987-f4ac-b188-b5dbf0dd9b30@dovecot.fi> <5726d51f-be68-470e-8200-a248ba6c97a1@sloti22d1t06> <30ea0a05-7322-8fe6-b8aa-74ca2162cd69@dovecot.fi> <5f090839-deea-b290-bf8d-956ba5cf32ae@dovecot.fi> <8e4ac10b-06fc-ab5e-7d37-56666aa9e9b8@dovecot.fi> <094d0f2f-0640-47b1-9109-f7522b8d64be@sloti22d1t06> <37993371-d16f-0f94-1a46-db66c29b7eb4@dovecot.fi> <3a2bfcc3-5e89-a35f-6f19-c08183c471cb@isode.com> Date: Wed, 05 Sep 2018 03:42:02 -0400 From: Neil Jenkins To: Aki Tuomi , Alexey Melnikov Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=e05654020a3140cb893c6ab003718372 Archived-At: Subject: Re: [Jmap] Review of draft-ietf-jmap-core-06 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: Wed, 05 Sep 2018 07:42:09 -0000 --e05654020a3140cb893c6ab003718372 Content-Type: text/plain On Tue, 4 Sep 2018, at 7:09 PM, Alexey Melnikov wrote: > I tend to agree. Implementors advice (even if it is informative) would be good in regards to caching. OK, I'll add some advice on caching to the spec; I've created a GitHub issue to remind me. Neil. --e05654020a3140cb893c6ab003718372 Content-Type: text/html
On Tue, 4 Sep 2018, at 7:09 PM, Alexey Melnikov wrote:
I tend to agree. Implementors advice (even if it is informative) would be good in regards to caching.

OK, I'll add some advice on caching to the spec; I've created a GitHub issue to remind me.

Neil.
--e05654020a3140cb893c6ab003718372-- From nobody Mon Sep 10 00:27:16 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 AB74412008A; Mon, 10 Sep 2018 00:27:08 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <153656442861.26589.1053891831241444605@ietfa.amsl.com> Date: Mon, 10 Sep 2018 00:27:08 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-08.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: Mon, 10 Sep 2018 07:27:09 -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-08.txt Pages : 69 Date : 2018-09-10 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-08 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 Mon Sep 10 00:28:52 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 3E026130E28; Mon, 10 Sep 2018 00:28:42 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <153656452221.26589.9540444584038568146@ietfa.amsl.com> Date: Mon, 10 Sep 2018 00:28:42 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-08.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: Mon, 10 Sep 2018 07:28:42 -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-08.txt Pages : 88 Date : 2018-09-10 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-08 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 Mon Sep 10 00:35:49 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 58136130E28 for ; Mon, 10 Sep 2018 00:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=kij6L9f9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Mytgm2CC 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 cK-gD1Cwpmjg for ; Mon, 10 Sep 2018 00:35:47 -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 F214C12008A for ; Mon, 10 Sep 2018 00:35:46 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2E32720E73 for ; Mon, 10 Sep 2018 03:35:46 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 10 Sep 2018 03:35:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:message-id:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Cj4nC2yg8N1EddE4X +vvt/0424n0MXA3YTGC7eGHulA=; b=kij6L9f9V+BantT0z4N5ComLLvhqi64nT nSScnbWpp4v0OJO75M7YoJ9/aKgRIU6h4G42CBPZxfBPUvfi0foFNKr/p/UtRB/Y XmNAygW7f47FXU6XmWQpyxmkR7cBoo97sTwoGmqsqc4kWI8s+JxR/pqJ29rRNC16 g1oTZb7fiyGlFGyEDQlSpHfAq19UihnEtk6FRkjeI9hsPgu4KpV7i6CwTOKkaQ4y LtRd3yyX9+S77X8tkNQHLGQceBtKNuTZYOOF8O9mba28p1nvQTM+g1gTB2HoRHAy 1bKyfQtD2pe/rhhH1scNC5KMrYXgRrjssYCPRyQN0Jr4CeN8tso2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Cj4nC2yg8N1Edd E4X+vvt/0424n0MXA3YTGC7eGHulA=; b=Mytgm2CCyM2pu1cfa3EA5zDC8e9sfC YRpXB2+9Rc/t0SjAwwEwdBAZyakT6Eh7sNFU7mxHt78G6b2BsSCeXHwZTjWfluJ6 hejM63bnp161UgAlFuh64Nletp0RdxUpXRpwbhqYgDsgcXxxWv5d10zT6qVTPjlI AZ4cmsOcjgiukv7dYDUJkQYeMk8wWPAwSUPOJngWX5fEE77K0DwkmHcEd/B4HsHI NXnzDX8Tqz3tU27wUeLc5onLO7rR5cB7HRqs/d+E6tP7UuoEKJa7LvRlESTKWGNZ +xIjfy+O96F9c3D/GvDiY1/tn3XAoC7rxNS3T4VBMlvLiLwo7JcOU1OA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 97862E6A2; Mon, 10 Sep 2018 03:35:45 -0400 (EDT) Message-Id: <92e56945-7221-4972-8a0b-a18c81680038@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-453-g95e844c-fmstable-20180907v1 x-jmap-identity-id: 64588216 Date: Mon, 10 Sep 2018 03:35:44 -0400 From: Neil Jenkins To: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary=c420191a16d74d9aa0b9bfc5ba90e205 Archived-At: Subject: [Jmap] New drafts 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: Mon, 10 Sep 2018 07:35:49 -0000 --c420191a16d74d9aa0b9bfc5ba90e205 Content-Type: text/plain Hi all, I have just uploaded revised versions of the core and mail drafts based on the latest feedback. All open issues in GitHub have now been resolved, so I believe it is time to go to last call. Core: https://tools.ietf.org/html/draft-ietf-jmap-core-08 Mail: https://tools.ietf.org/html/draft-ietf-jmap-mail-08 Cheers, Neil. --c420191a16d74d9aa0b9bfc5ba90e205 Content-Type: text/html
Hi all,

I have just uploaded revised versions of the core and mail drafts based on the latest feedback. All open issues in GitHub have now been resolved, so I believe it is time to go to last call.


Cheers,
Neil.
--c420191a16d74d9aa0b9bfc5ba90e205-- From nobody Tue Sep 11 16:39:33 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 6D9C3130F47 for ; Tue, 11 Sep 2018 16:39:31 -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=DdDgl9KQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KZu/p4AB 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 XzSwbDMg_nIl for ; Tue, 11 Sep 2018 16:39:29 -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 05D9B129385 for ; Tue, 11 Sep 2018 16:39:29 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 28B9821D2B for ; Tue, 11 Sep 2018 19:39:28 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Tue, 11 Sep 2018 19:39:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:message-id:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ulDvPyuE/GyfTjYAy MF6fLBc5ObAHOYtop1/guF/cPc=; b=DdDgl9KQjxjp0MOsFl0rLaKjh+zrjfVQW lStEKd/Mkb7TB74qA970krin3A4e/gSrC2tYvw0cveDNPoRxRbQDG8r4TETk5zJj hN/sn7ebEhcJgHW20V1Db1towYQP8LtRsAla1+VX/rbQ8j5CnPJYZ9dBcufa2Omd KbdzqQ2Herqguqv77TQCY0NIaNC/eQJTCRmE6vPTBhkXp+libnNggpBbVZ7/6zBK Y5rAPHsJn2kxxlb+5IGhlFgK0R1qb9++TuWqv9neq28rlz1Sy4o87M0UlnDUDFBF w37spPVLeLkQFTJty1EXpyavQB2BwlCfuQ/Nw9gqmMlCyl0zMFHbQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ulDvPyuE/GyfTj YAyMF6fLBc5ObAHOYtop1/guF/cPc=; b=KZu/p4ABmGEZXwvjW8TuT4IclcSpuj 79i552kNWAeisARo7WdIy/DqNn6l84Qf6GIeBx91HiCGU3NGLYt0+K1j3nWbqmqi kUVZiZFCjR62cPjXy/fHlNLTcx8fOlTHv7AC0BUWb2WnHWHE51s2FenXZbyfDGBD qhPfqz3PmDgB0XowoojNWiB0T8hq378Re2IZG5vCnQjcAJT1bhMl/czDkLMBTvdQ e5BxN1yBBvBZ1avVdw6qDrioHCGvE8hg/Cr8cHp2jbF6L0KKkHjwwDNd+MlL8NRR mFzQAJMXvqJZqBqKVpqOHeBud2Uq7J7dSgojLhv5RG7GU+csC7ZN4D/g== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 68B44E6A6; Tue, 11 Sep 2018 19:39:27 -0400 (EDT) Message-Id: <840f5957-d806-43c9-af60-902a92ae9747@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-472-gf55f9be-fmstable-20180911v1 x-jmap-identity-id: 56629417 Date: Tue, 11 Sep 2018 19:39:26 -0400 From: Bron Gondwana To: jmap@ietf.org Content-Type: multipart/alternative; boundary=412c4c2815b1492194f59c6bc1350849 Archived-At: Subject: [Jmap] Working Group Last Call - jmap-core and jmap-mail 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, 11 Sep 2018 23:39:32 -0000 --412c4c2815b1492194f59c6bc1350849 Content-Type: text/plain Hi All, It's with great excitement that I announce the working group last call for the JMAP mail and core specifications. In particular, these two documents: * draft-ietf-jmap-core-08 * draft-ietf-jmap-mail-08 Due to the complexity of the documents, we're declaring quite a long working group last call - just over 2 months! Please use this time to review the documents well, and also to implement and test the specifications. Working group last call will expire on November 16th, which is just after IETF103 in Bangkok. I expect our session there to include discussion about any issues raised during the last call period. Regards, Bron - on behalf of the JMAP chairs. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --412c4c2815b1492194f59c6bc1350849 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

It's with great excitement that I a= nnounce the working group last call for the JMAP mail and core specifica= tions.  In particular, these two documents:


Due to the complexity of the documents, we'r= e declaring quite a long working group last call - just over 2 months!&n= bsp; Please use this time to review the documents well, and also to impl= ement and test the specifications.

Working group last cal= l will expire on November 16th, which is just after IETF103 in Bangkok.&= nbsp; I expect our session there to include discussion about any issues = raised during the last call period.

Regards,

Bron - on behalf of the JMAP chairs.<= br>

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


--412c4c2815b1492194f59c6bc1350849-- From nobody Sun Sep 16 04:11:22 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 AF6DD127148; Sun, 16 Sep 2018 04:11:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, brong@fastmailteam.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153709628071.16991.5358596774044292318.idtracker@ietfa.amsl.com> Date: Sun, 16 Sep 2018 04:11:20 -0700 Archived-At: Subject: [Jmap] jmap - Update to a Meeting Session Request 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: Sun, 16 Sep 2018 11:11:21 -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): 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: 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 Sun Sep 16 04:17:48 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 B5D3C130E14 for ; Sun, 16 Sep 2018 04:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=HUGcRuta; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=furRCHlR 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 k9d_KOobj6DN for ; Sun, 16 Sep 2018 04:17:45 -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 19731130E13 for ; Sun, 16 Sep 2018 04:17:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3B70521F14 for ; Sun, 16 Sep 2018 07:17:44 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Sun, 16 Sep 2018 07:17:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:message-id:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tPS6U0K4US9zXz4vq nKJnXT4ueVm2BZaZWLbWrbCxTo=; b=HUGcRutaJmMLgzQcYsjMAsmz90Elk8OzZ nCdNgkl5FBWybPJ4EMjBLBmoUAi7bFIFJ2e4PBphRT+dm+/S+PD9Y02wYwVP/DYJ 1EsjKOatKBVLoSmV7i5AewFxbq8bzN6HJZ7Qgt0p5ji1hk0KHhuC6BCOQXTTnjOy yQKER0I3ElpSDmCavqPMXCyPntgwhpTeKPvHiHOkb/tRhRoRbwCEZR7/k9en8orx lI7svcEsZe880HMRoYFh/NDhXaEAdGC+GGFMMQ3wyfC8lPuvaAPTwvscyXiB+IEj /QzgF4Q3K16HBZWDLfd0kqBsz701kzkeg0IiTlgJ29FB0kA5CwrBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tPS6U0K4US9zXz 4vqnKJnXT4ueVm2BZaZWLbWrbCxTo=; b=furRCHlR7DNwmdmLx0NEtvS8QK7AyF BRaalR73x3T/xI04QVRbGQO3I9lQrHu9qfqcAt8MiqHSoEoI1VaidI5fLLAAYoRa DVJrKzL2KWOGzN80Qy0HXd0h/H6bhIvQXGJWLia7KrwKcTh6xkxOYgN9UpjdabyR QETA7y2LqESN+hdsSP5jwPJtajiGc1Rhm28nAiPiNBJQcfsABxWhjLPJCzd9Tw1/ L/HiBD92HtTqOjUD1YOAH/zn9bwNqGLerqOrRa50eXxBUuhxR75utsrkrJmAqU4F XtEsQ4+Ng1Zegyw2RE21M2Xxt+PM5LTn9bnxEdMYzcGaQ6PEynmGb06Q== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EF331E7A5; Sun, 16 Sep 2018 07:17:43 -0400 (EDT) Message-Id: <264dab7d-fa39-4dba-9bfe-9bb60cfe996b@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-486-gb761102-fmnext-20180914v1 x-jmap-identity-id: 56629417 Date: Sun, 16 Sep 2018 07:17:43 -0400 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=bcb1de0495234609b8c20519f397e1bf Archived-At: Subject: [Jmap] JMAP Session at IETF Thailand 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: Sun, 16 Sep 2018 11:17:47 -0000 --bcb1de0495234609b8c20519f397e1bf Content-Type: text/plain I've just updated the meeting request to say "please not Monday" since I have discovered that I can fly out on Monday morning from Australia, so I can get there in time for Tuesday onwards :) I've also asked if it can be scheduled next to EXTRA, since so many people attend both. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --bcb1de0495234609b8c20519f397e1bf Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I've just updated the meeting request to say "please not M= onday" since I have discovered that I can fly out on Monday morning from= Australia, so I can get there in time for Tuesday onwards :)
<= div style=3D"font-family:Arial;">
I've also asked if it can be scheduled next to EXTRA, since so many= people attend both.

Cheers,

Bron.

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


=
--bcb1de0495234609b8c20519f397e1bf-- From nobody Sun Sep 16 14:47:50 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 311D6130DE3 for ; Sun, 16 Sep 2018 14:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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=zonevs.eu header.b=rxa9NvAp; dkim=pass (2048-bit key) header.d=srs2.zonevs.eu header.b=vhKDsvMD; dkim=pass (2048-bit key) header.d=dot.ee header.b=p30fSFTe 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 quUdMLPGFdw2 for ; Sun, 16 Sep 2018 14:47:43 -0700 (PDT) Received: from srs2.zonevs.eu (srs2.zonevs.eu [217.146.68.192]) (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 4ED25130DDD for ; Sun, 16 Sep 2018 14:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=Lgla3JaWYHzPbCcIBj9+H0kK65yW3bOCJuvkuLama00=; h=from:subject:date:message-id:to:mime-version:content-type; b=rxa9NvApOpbw2JvZkD7DlCEcbeI45VEKGlMrHQ6q44DjEMT1rzEnKl3rH205ewGVVDMDDyigC 26pjhQONpXzBVmN1OSAJvP9UVMq3kLW6FB1nARpEIwJNCHEphtKBbEySLFinIVC7t0auXEJa5ZI HOESZdPFfAF3Pa4zuz3Wcz+fgc9ZQiiYNtV3EAknCNA93jp0b8snVSxQWvSUIThQsnmIsxuXiAq p/Mb6ydiqvwTGx73HfNU4EQeZvZpSz/I8ZVCxo+ZjXlYENYsmsMT4VcheDZD4f1xgn3PI0zkjS6 3+6v5CDD6OjGJzAPdwyfTjRGIYXCzKEbFpbj1CzDU1VQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs2.zonevs.eu; q=dns/txt; s=oct2016; bh=Lgla3JaWYHzPbCcIBj9+H0kK65yW3bOCJuvkuLama00=; h=from:subject:date:message-id:to:mime-version:content-type; b=vhKDsvMDwFN942BFImfwqOr6rR3MGKMO9L8aIldWSTVK2ZiCEnobXDRKNpBwQsAbbIx2sgxWc 1KTvayxEj8h7s7FYTfUdDxUo46LRxzTb3XXMTdccd5T5A6dl8YQ8nKMt51uftYBFWX7PRGwU3U1 XKvxzKEOZFyg39jSi0VXTjZnXcpZ8scUP5RxnDC+aLpOASgkhrv/A5kdlbhD5zukwvsPrbEjuZ3 q4H+hY0ZjphywgqGa80ut671gUcuSaFe11ZWPwWLndD1cHoOKFQcOee8Uc4hPgrXJGkDWf6pbHd j/oNYoqW0EMnSy+SY3gN1PfYcqFoen09fdwiTVSIHsag== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs2.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165e45a752c0001e91.001 for ; Sun, 16 Sep 2018 21:47:38 +0000 X-Zone-Loop: 8ddc71c5b0c8f01db077d93e0ddc0dc53ea15e54d17f Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.ee (Postfix) with ESMTPSA id EE594128B5CA for ; Mon, 17 Sep 2018 00:47:37 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1537134457; bh=34UC1Mgov21BtObgZsDEM6SMz2L+TBZSRP5hjnLFlLo=; h=To:From:Subject:Date; b=p30fSFTeOd+VM541BwyWhx3TxomeNHZa88ZP+7xR2T5M2Uj7jp+aMFCMkSnOErFHg 89s67YxBAtqULQKvOYu/cu/UdHyh+K4Fsyb0C96wskXBaQsLinj5LgRpMsabJrYcKi gfriDvsPmw5I7rfBYPvJbXHZDuzomSBEoQ/F7D8AcXw5xTYHO43t3RjUFd8RTM/7Wn kkHeqbrPdGKkBVbhgRcp5oKXUd6o6xc1U5G3/yD660niYrnHUkn4BF561YlWkYVLLj gF/b1thyFfkcUuMX5yu1pFBFhAhgqm9X6n/+ZWRC4uNbXwPn5irORXFXmo2KnkjBAR F2gIEorrNhkKg== To: jmap@ietf.org From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> Date: Sun, 16 Sep 2018 21:47:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9253C290A695CD1374B2E138" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-3.120909, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.920909, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Sun, 16 Sep 2018 21:47:49 -0000 This is a multi-part message in MIME format. --------------9253C290A695CD1374B2E138 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I raised a similar issue with JSCalendar and I thought I'd seek what others think here, too. This is about unconditionally requiring HTTPS in Section 8 with no explicit (e.g. a warning like from today's mail apps) HTTP fallback. Long story short, suppose I come across a 3rd party JMAP client on iOS that fails to work with my JMAP server. How am I expected to debug the problem if I can't direct the app to a development server on a local machine? I'll quote myself from before: > I've spent hours debugging and working around iOS's (and other > platforms') CalDAV quirks and managed to so by directing the apps to a > development machine. Yet if CalDAV had demanded HTTPS to the server, I > would've been hosed. You can't get a legit certificate for a local IP > address nor do I have a Mac to install custom root certificates to an > iPhone, for example. If that's even a thing anymore. Some client > software have their own bundled roots. There it would've impossible to > productively debug HTTPS-only services. > > This is a weird thing for me to advocate, as I'm usually the first to > jam encryption down people's throats, but my latest experience with > implementing CalDAV has left me with quite a cynical view. While > people _have_ to follow standards, they don't. They make mistakes. And > that's where obstacles to debugging annoy me. I'd like to see some considerations for the implementors of [JMAP] servers here, too. Andri --------------9253C290A695CD1374B2E138 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi,

I raised a similar issue with JSCalendar and I thought I'd seek what others think here, too.

This is about unconditionally requiring HTTPS in Section 8 with no explicit (e.g. a warning like from today's mail apps) HTTP fallback. Long story short, suppose I come across a 3rd party JMAP client on iOS that fails to work with my JMAP server. How am I expected to debug the problem if I can't direct the app to a development server on a local machine?

I'll quote myself from before:

I've spent hours debugging and working around iOS's (and other platforms') CalDAV quirks and managed to so by directing the apps to a development machine. Yet if CalDAV had demanded HTTPS to the server, I would've been hosed. You can't get a legit certificate for a local IP address nor do I have a Mac to install custom root certificates to an iPhone, for example. If that's even a thing anymore. Some client software have their own bundled roots. There it would've impossible to productively debug HTTPS-only services.

This is a weird thing for me to advocate, as I'm usually the first to jam encryption down people's throats, but my latest experience with implementing CalDAV has left me with quite a cynical view. While people _have_ to follow standards, they don't. They make mistakes. And that's where obstacles to debugging annoy me.

I'd like to see some considerations for the implementors of [JMAP] servers here, too.

Andri

--------------9253C290A695CD1374B2E138-- From nobody Mon Sep 17 03:17:27 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 087A9130DFA for ; Mon, 17 Sep 2018 03:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 p713MH9sAXUa for ; Mon, 17 Sep 2018 03:17:25 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C26130DE3 for ; Mon, 17 Sep 2018 03:17:24 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (localhost [127.0.0.1]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 60669C0660; Mon, 17 Sep 2018 11:17:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1537179477; bh=XTuQ6qNTN6N1qz9ObaQ07p3O8yufzY8KAYwmlsSE7NM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WJLgmWogrL0c80OHjikoHX2Uimv98xscVl7iv8KKUGIuk/4qDnv+KwMNw3LCvOb72 kxPtlqoYqpDRcnb72mRQ9U6acADLspjW56z3xRCzv+FO5GDhQyExlASzPDxfOohfpC iL49u1oJOQK3yCPA34SD+pSZ4PstIGzNB/4Qkyi0= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1537179475-23985-23983/9/76; Mon, 17 Sep 2018 10:17:55 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 17 Sep 2018 12:17:14 +0200 Mime-Version: 1.0 Message-Id: <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> In-Reply-To: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 10:17:27 -0000 > How am I expected to debug the problem if I can't direct the > app to a development server on a local machine? You direct the client to a development server for which you have the private key, then install that private key in wireshark and tell wireshark to decrypt the connection. One of these should help: https://www.google.com/search?hl=eo&q=wireshark+tls+private+key Arnt From nobody Mon Sep 17 03:46:28 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 D778A130E1E for ; Mon, 17 Sep 2018 03:46:26 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=zonevs.eu header.b=Lx5JcDb7; dkim=pass (2048-bit key) header.d=srs1.zonevs.eu header.b=E9dW54/O; dkim=pass (2048-bit key) header.d=dot.ee header.b=XmqlD/zS 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 GEzBErWtkAbl for ; Mon, 17 Sep 2018 03:46:23 -0700 (PDT) Received: from srs1.zonevs.eu (srs1.zonevs.eu [217.146.68.191]) (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 863B9130DD7 for ; Mon, 17 Sep 2018 03:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=bCoxUiNMGxyZmO4KIYGhrCw0SeCHYFB9HxGGxGyCE1M=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=Lx5JcDb75pQueyYMqKCx9dM3XaPi+KJ9QZrBDFGpl+0Gmpe0EFjmvVP+3yMHdrzaAIxE2pJQ5 YjUdx/41rEu2EZzMyWwsem4oj3RVGH4bu9TQbSYMe1zA7YjoRN3a77gcjtvxgGAAcu417L9h738 e1DWTvOxkvxoHLGrU2wKn6pSKdbxMcC/gIWLBmCKvh7Om7TKqaeZv2As+TxGLg40PVbkmb4mtbG oK97PPZsJlvwbsH8I3zOaDJAjKd2ciIkAdCSyLQqWQHfCXPelXhNPxXl89BntmO3X+o0fpLuAH0 QxwGW588/w++VNDxzSujkxT9ehIn/5TxJetFv3nVdJ7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs1.zonevs.eu; q=dns/txt; s=oct2016; bh=bCoxUiNMGxyZmO4KIYGhrCw0SeCHYFB9HxGGxGyCE1M=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=E9dW54/OY1c/s2dDh4wSBR/woKLVKrl+CZhvmMoAwEv9VGQIiWDVoWkyQxuyMyUd4r3+uHdjh xG8Fo9bvhOWY+ALUgpy5YViVogfyHkrc8rnAgYJxKQoUE9JiBLy9qXwKVlJR93NPaUaAmnsyjAE wradotiwD0DxHNM2xb6t9/bl6WfzwWUkyVYV0Idd45ZqjX+fvKumDsgNZ1tbAPi40PQwy3Bgstr f+U2zq5a3Pv/MqeFfBHWiwuESnWSxtp6q62uuZY6aKpgCW/VdwhxR+GnSbE/R5dmfbf+sF1QEsn e+uz9u4ohemjMdA155cEowJUQZjJNfUzgmJaDzCqSTAw== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs1.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165e7235bc70001e91.001 for ; Mon, 17 Sep 2018 10:46:18 +0000 X-Zone-Loop: 8fa0194b3811ff564d997fb01d721bf79ad08669cf9d Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.ee (Postfix) with ESMTPSA id 340CC128B5E6 for ; Mon, 17 Sep 2018 13:46:18 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1537181178; bh=OCX9+3j4+ttqbOMXq6CPJh317M50XCMofGUuxai5jis=; h=Subject:To:References:From:Date:In-Reply-To; b=XmqlD/zSoDYMoWYETxTjxc+8W952f0VLpWshEdRWGPn+QabL/fBgjhlCKfIFIoqGc tMZ+CrfblLOMkCUvDTi05scmEgaPOeQrWpo/bvNB0nOefMmI3wjpCqIcA7THaGPt1A VvjuHGqPC3fUS0W36L41GJXm7DCGMisTeJ6gdim/ApcPx5RgWYpRw0Wtd2jvoxl6YL gY+yKC9w/CF49lPJF7/fFKynvS7HQl4AhOSJyG6QExMDtojyKsX9EP2v4O5koIDUKm AGDOteD/TbP+v9k4svPyHnIMCtVl2jcGiQRrzWYga0JV9sDUa8wR1313z6jiN4TyJC al21+glBV0oKg== To: jmap@ietf.org References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> Date: Mon, 17 Sep 2018 10:46:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> Content-Type: multipart/alternative; boundary="------------D4BA0EBAC07066A53116F690" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-3.137343, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.937343, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 10:46:27 -0000 This is a multi-part message in MIME format. --------------D4BA0EBAC07066A53116F690 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Well, unfortunately that's not going to cut it. Debugging 3rd party software is more than getting the plain text. It's an iterative process of trial and error. Secondly, the biggest problem is getting an accepted certificate for development in the first place which I described in my original email. The more "correct and secure" the 3rd party app is, the less possible it is to test with it _if_ it insist on using HTTPS. On 9/17/18 10:17 AM, Arnt Gulbrandsen wrote: >> How am I expected to debug the problem if I can't direct the app to a >> development server on a local machine? > > You direct the client to a development server for which you have the > private key, then install that private key in wireshark and tell > wireshark to decrypt the connection. One of these should help: > > https://www.google.com/search?hl=eo&q=wireshark+tls+private+key > > Arnt > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------D4BA0EBAC07066A53116F690 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Well, unfortunately that's not going to cut it. Debugging 3rd party software is more than getting the plain text. It's an iterative process of trial and error. Secondly, the biggest problem is getting an accepted certificate for development in the first place which I described in my original email. The more "correct and secure" the 3rd party app is, the less possible it is to test with it _if_ it insist on using HTTPS.

On 9/17/18 10:17 AM, Arnt Gulbrandsen wrote:
How am I expected to debug the problem if I can't direct the app to a development server on a local machine?

You direct the client to a development server for which you have the private key, then install that private key in wireshark and tell wireshark to decrypt the connection. One of these should help:

https://www.google.com/search?hl=eo&q=wireshark+tls+private+key

Arnt

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--------------D4BA0EBAC07066A53116F690-- From nobody Mon Sep 17 04:00:51 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 CAD24130E10 for ; Mon, 17 Sep 2018 04:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 5Hv7n7a1F58a for ; Mon, 17 Sep 2018 04:00:47 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435BD130DF9 for ; Mon, 17 Sep 2018 04:00:47 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (localhost [127.0.0.1]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 6ACACC0660; Mon, 17 Sep 2018 12:01:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1537182080; bh=1fLb0V1viSoCCoCnEdwZo3RsHrZMGW3lmjgj8HFqybw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OL1zqMGm7lHuMxsRsT4bmsfXNIw3P2lGcf+yf4lpNe1xgn0b0FNpXZnW7glrFk8Y+ rxnk+HE+oa03xUWSOEisXgjFehhxlNfpmR9KexbdE8f0ZIgwtGpPkmqMszEJBWpqkj dT4kJVS3k3Kr7jMK4XBJC/v5kmJYz+vIMHKDeOWM= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1537182079-23985-23983/9/77; Mon, 17 Sep 2018 11:01:19 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 17 Sep 2018 13:00:42 +0200 Mime-Version: 1.0 Message-Id: <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> In-Reply-To: <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 11:00:50 -0000 If you need more than just getting the plaintext, then relaxing the HTTPS requirement won't help you either. Arnt From nobody Mon Sep 17 04:04:36 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 38AFE130E04 for ; Mon, 17 Sep 2018 04:04:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=zonevs.eu header.b=G3HmSYgA; dkim=pass (2048-bit key) header.d=srs2.zonevs.eu header.b=HFqOITDT; dkim=pass (2048-bit key) header.d=dot.ee header.b=cxL4jKTK 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 mioXEcBs4Qkf for ; Mon, 17 Sep 2018 04:04:30 -0700 (PDT) Received: from srs2.zonevs.eu (srs2.zonevs.eu [217.146.68.192]) (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 2882C130E10 for ; Mon, 17 Sep 2018 04:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=Yx7ODQoQmSyNlxuU2B9qExtrWzslx38e47JXWrJRsO0=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=G3HmSYgAsdMRgUrkJqPSVmo54KEVxhBGPYWVj0jIyOMDM2PUEn0NosViqrKsF7vJ23MvZP5Rm 1GYj0dgHmrV7l367E5GvF/4DuUiOe5Rlg3Ss3CananFnt3hM5ot5rr1wTKRvT/cp1MaIZlkY7Ri 04zVWfmxVYN5NqSzfGYfFW9oEb7O5uwfsIs7TKHJE3+bwpkg7zfJehjQ4h4S/Ozy+KwDb0wrHSz dsevqFPRnhe+srgZ+5HDrsvS9cCkJeWhXVThTpSvH7FSB0v13rR/a3DxEc0MJa78s90hVe0bTAu jPLpgWRAVUHQLn8WyML6VcL92S4quuMbvjtlpHxcvEkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs2.zonevs.eu; q=dns/txt; s=oct2016; bh=Yx7ODQoQmSyNlxuU2B9qExtrWzslx38e47JXWrJRsO0=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=HFqOITDThcc10sqbot7mLa/IccNSJam5QPK2KjZHC7S/HUymQVnmPexPBSfddgea3lyN6UVVB WKiLp0iRWYz2SF4FHIZa6DuokeT1fKEPbA0Wjeqrb/qh+zRQctrB4YzKY+CshP/1ukjpOyZ9fhT MZoOoQUOWoNE9iYQwux5DezLu54n0LJlKmrwz4+yIlwtWWQ4rDjCSFscBhB2BZ1Ty9N4HYvqKgz ISnN70vEfUXv48rx856wa4MNYh1aG22KWLPNEuuEzcA8uepLrKulF7jCWuRoqYklgUYkbncKCgc VUHMrsDDw1nCodtYo4ZQaRO27msdO7bp4Z1LYHKPHsOA== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs2.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165e733f94f0001e91.001 for ; Mon, 17 Sep 2018 11:04:27 +0000 X-Zone-Loop: 2609840d40b7e43281d78d4183f738d9e6c0c5f63dc5 Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.ee (Postfix) with ESMTPSA id 9C39B128B5C5 for ; Mon, 17 Sep 2018 14:04:27 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1537182267; bh=ycmt27NLNZrIf3NLOByZQC6v8pS8brelKSFM8PXhZF8=; h=Subject:To:References:From:Date:In-Reply-To; b=cxL4jKTKZfWJKgywQFHgAI5M2Z3U3tA9iYMnxRXeecx0NDfdEh/OWXZc1vByPR9Ej ngU9Ufdaj4tHok4WnEJfcQjLfru2n/POPHFpwcD4UIZL6ZubsaQ20IZF59eRMkAxrC +tv+oraGGVjBl+bpS2M5+P2fjBlPUDJ5Dqg0igHS9c1lLH27gS8LxsKr9sA/dYZBhL Qs9sixRjPVU7h/7/JJcogQC3d2Yl+m5PVmQ55TwdB/a7tR3QVH/AKpU+tBYQOz5T2y +cPuKeyGLZ+VbMLZRnv52CuDVZUppqwKVy+kvS/t+IgNq6Ln6t74SqPG5LejFMhjX1 rDgSvvER3kucQ== To: jmap@ietf.org References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: Date: Mon, 17 Sep 2018 11:04:26 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> Content-Type: multipart/alternative; boundary="------------BA6D7697743E22B4B84ADC38" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-3.145117, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.945117, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 11:04:33 -0000 This is a multi-part message in MIME format. --------------BA6D7697743E22B4B84ADC38 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I think we're imaging something different. I'm talking about a JMAP-compatible client application providing a way to talk to a given server over HTTP just like I can configure IMAP or CalDAV compatible clients today to talk to a local development server over plain IMAP and HTTP respectively. On 9/17/18 11:00 AM, Arnt Gulbrandsen wrote: > If you need more than just getting the plaintext, then relaxing the > HTTPS requirement won't help you either. > > Arnt > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------BA6D7697743E22B4B84ADC38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I think we're imaging something different. I'm talking about a JMAP-compatible client application providing a way to talk to a given server over HTTP just like I can configure IMAP or CalDAV compatible clients today to talk to a local development server over plain IMAP and HTTP respectively.

On 9/17/18 11:00 AM, Arnt Gulbrandsen wrote:
If you need more than just getting the plaintext, then relaxing the HTTPS requirement won't help you either.

Arnt

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--------------BA6D7697743E22B4B84ADC38-- From nobody Mon Sep 17 04:26:52 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 6FC79130DD7 for ; Mon, 17 Sep 2018 04:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 lU5PnIb6vq_0 for ; Mon, 17 Sep 2018 04:26:48 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74E81277CC for ; Mon, 17 Sep 2018 04:26:48 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (localhost [127.0.0.1]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 181FEC0660; Mon, 17 Sep 2018 12:27:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1537183643; bh=JNskhegz7OC0rMfW761fC7tdgWPKKzeJw9BVQHpYsmg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n4Pw4Ke7OuA1/PpGmb71G8U2Dm5TF1j/4CJUCagudyI1a0nIUyLcgOaywLXPm+1Vz IFpkwyHEySyc/RtcR8TwnEDD5+maZHqGYySDh5XnF8/BWmkC5vCKiSPbZwBOTLMHqQ JDWySwtxCUiWFp6zeb2D2Jw/f6FHvAb4f4TskTWw= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1537183642-23985-23983/9/78; Mon, 17 Sep 2018 11:27:22 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Mon, 17 Sep 2018 13:26:46 +0200 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> User-Agent: Trojita/0.7; Qt/5.3.2; xcb; Linux; Devuan GNU/Linux 1.0 (jessie) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 11:26:50 -0000 Maybe I misunderstand... what does requiring support for plain-HTTP transport achieve compared to decrypting connections? Arnt From nobody Mon Sep 17 04:28:23 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 7119A130E04 for ; Mon, 17 Sep 2018 04:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NW_Onsbe82UI for ; Mon, 17 Sep 2018 04:28:21 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id C736E1277CC for ; Mon, 17 Sep 2018 04:28:20 -0700 (PDT) Received: from [10.217.110.125] (officegw.dovecot.fi [193.209.119.1]) by mail.dovecot.fi (Postfix) with ESMTPSA id D8E04227A40; Mon, 17 Sep 2018 14:28:11 +0300 (EEST) To: Arnt Gulbrandsen , jmap@ietf.org References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> From: Aki Tuomi Openpgp: preference=signencrypt Autocrypt: addr=aki.tuomi@dovecot.fi; prefer-encrypt=mutual; keydata= xsBNBFb7bukBCACpK7GFwH/gyL0oF8t91WM7S+UjuQ1vOQZg2eoCUHi4ILpm1Kae4UeZLB2X Vbeph+k29BIQbo+Hjv6rq6JzPfKIZCRLLrkMD1MtA0YB7ZYiACywLrATAdAMJ6sRq+DL5Rlr A2CvviTifz6DwEnbqI+ckcKggsY2gywHs5muDw+n5TwLiL0V9IU478vg7OUWzMZ42toTmeTW 2MtsIAE5xbnjZ58LUSZR2CNO8SAtDHYI558ACkS0wHBAoRFNv27IPr3cebiPsIglSEIBr0R1 F1Twbgm6mWVBhK+smDgGxmmuAhH6boSaKWoWAq+tNf+6oXnr3/D0IPtR8c/bZobtvWG3ABEB AAHNJ1R1b21pLCBBa2kgPGFraS50dW9taUBvcGVuLXhjaGFuZ2UuY29tPsLAfgQTAQIAKAIb AwUJEswDAAUCW2P/aAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQGTtjY7NEQgYmMwf9 G5U0+vKJB+f3Vl8rjPqlXmUZu4waf6pig5lLCrgu56ZkqEDmjaxmxXAah7JZ6dD/66kzlQzK QPYpLor0KnTZgm8XZr+MtqLK8DMF/4+iljADvkS4nfJuX3LbdafPyuk4x+GIa+6NJ+y34jZ2 84Oesj+FtPOevthR9rDmnc2KQjBD30ceKsadxIKqWPYPqPESQ0PyMu9tOaWNdGntx8LvO3Ll spZ2DzEh5rregFKtO01jR9ai5r3mbUrQqwzWLxJztBYjds8D5VAiCBeivUxetDqhoPr3CyKH Stc5GfgHvazjG34H+CShReqIylfR4mwc654qkmVQfPMMUTaa677n8c7ATQRW+27pAQgAosZd RB8tui65tjna4iYKPHqcNDZUXOUuPLTucYc2tY2v67POGr44gOZNzuQWKyXRSBs+Q2zJHcbc cPe0ZEptkOCOwdhhvBwZLKa6nI9jnJ0K+szT2NbD0YkvaIDALA9pVGMJqa88wvkkocf/I5fk dTk6xuLp8AamRXvcPZuUPo/s2PXQV4u+gtKdX1FmaHiBg1oQhtoDWZO04H74r9fyPPs499ra 9iNckSlZP51OUFBbV/RmbtEC031r4iXUAgiL0nQ1mNpRIW+PU/5beX/4YwYeCpzy7g0XfMaJ oMWDamRdXgzkXK6IJIxwo/89M8qPW+Bkh88yAennI2SsEvniXQARAQABwsBxBBgBAgAbBQJW +27pAhsMBAsJCAcGFQoJCAsCBQkSzAMAAAoJEBk7Y2OzREIGCm8IAIZkj5FClx8EmPy1caC+ CNv1mVrC2YhKY9Zh255JUtt+Xp6tshN6IOr+saNkcwgUghxmx6+asZXPDHTqhXoswPi28k1u CY7n4gvh3jlS7a0HeI0sy2RCsrkIaQD2uSt+ju9fpEM2aOXQHGT/x6gZhJ7Uwu+JfDnCB7CB FjVnRaV2/87Y0ZImfhIMPYRzwOyWW6KR+JPIutyZAWo9c7mmjKbySLXhqgZariMJU+RQF5/d aQsiRJKP1IkC/Ncy/iZSnGvPIRZjvQxtrz+4xexZX6NjG7IbKAwmbo1t27cF3hE4HejakF5b LOhznVWubhjXp1J6pL9fymHmG2tZPsgwXcA= Organization: Dovecot Oy Message-ID: Date: Mon, 17 Sep 2018 14:28:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 11:28:23 -0000 On 17.09.2018 14:26, Arnt Gulbrandsen wrote: > Maybe I misunderstand... what does requiring support for plain-HTTP > transport achieve compared to decrypting connections? > > Arnt > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap Or you implement debug logging in your client / server so that it can be instructed to store the raw chatter in some log file? Aki Tuomi From nobody Mon Sep 17 04:34:27 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 689C6130E04 for ; Mon, 17 Sep 2018 04:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 ICCpoxg8TeVV for ; Mon, 17 Sep 2018 04:34:23 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B4718130DD7 for ; Mon, 17 Sep 2018 04:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1537184063; d=isode.com; s=june2016; i=@isode.com; bh=178qKPcYZrrgGsr4EI12rcKa2YuqiZvS96uSOihxPFE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Ow0sW33bMJnij4vhdXFbgGgcea+xvafhZYRpPQa3hFbXYGG2u/ACRkWejkdtUVDVbmxZMw qFtG8crpyO1J71Yyqx6K2gyX0PNigEpDkXA6K+b/vI7tiCf4h3JdfmFpYI370XVZdCMkMO KlZhAruGEkeloBMM5cXl7tPs3PFHVro=; Received: from [192.168.1.105] (host86-147-197-96.range86-147.btcentralplus.com [86.147.197.96]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 17 Sep 2018 12:34:22 +0100 To: Aki Tuomi , Arnt Gulbrandsen , jmap@ietf.org References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> From: Alexey Melnikov Openpgp: preference=signencrypt Message-ID: <0400d96c-14e2-b186-b1af-91c9049041d1@isode.com> Date: Mon, 17 Sep 2018 12:34:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 11:34:26 -0000 On 17/09/2018 12:28, Aki Tuomi wrote: > > On 17.09.2018 14:26, Arnt Gulbrandsen wrote: >> Maybe I misunderstand... what does requiring support for plain-HTTP >> transport achieve compared to decrypting connections? > > Or you implement debug logging in your client / server so that it can be > instructed to store the raw chatter in some log file? +1. From nobody Mon Sep 17 04:39:45 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 27428130E1C for ; Mon, 17 Sep 2018 04:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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=zonevs.eu header.b=0c4nIUmK; dkim=pass (2048-bit key) header.d=srs7.zonevs.eu header.b=xE0fzSTs; dkim=pass (2048-bit key) header.d=dot.ee header.b=U1XqQE2X 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 QgDG2K1sqfMD for ; Mon, 17 Sep 2018 04:39:41 -0700 (PDT) Received: from srs7.zonevs.eu (srs7.zonevs.eu [217.146.68.197]) (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 C9617130E2E for ; Mon, 17 Sep 2018 04:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=4gJCriB7ZEnSoRGOGNVDVWb9KC62ZGc9rxwnRtCVZs8=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=0c4nIUmKFqFgUQ8eoFlnPwnaokjGZ7MmQZ0bX1gL9T65PXeVLS09d1JzYdjodMouo9uXGXLNU zfpdWN6MTEk7YnzlEkB0RW7Y2/hR4Bh6FDsvGuMSthskHjRSQv38i83juEKKXs/7FrRe72fXl66 Pt83XEslZdN+LHvDS6GG0VbgMNwW+RgopRCF6AJC4LxUvavmQcaLuauc7TebB6bE/q1kWUSYV+N sc/6W2/CGhDK5K+xKizcMpkSUA73NFov4PYSTv4Lkh2sLINEAam7rCvfDnOwL67oYcLWCWoUDao oe9YopJF9uUMbxYCTUaPEBHtfCfRR8rFd5xve1mjHkrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs7.zonevs.eu; q=dns/txt; s=oct2016; bh=4gJCriB7ZEnSoRGOGNVDVWb9KC62ZGc9rxwnRtCVZs8=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=xE0fzSTs0XLhh3wJqqDcrwvhjvQDc6WGF55+0sT3kxfNgEu1fgEoFMh27a6EcUwmYq1OE0dXO ZVqiMMhp5fU6nFnIh99eTD8G3/nuVqMOnitYLQkXJx/0UlO5VPY26aMEBwru6jXuJc2rawr4Xtv iKms4qFLBM9xl/O2SDXJPtfkhEVM4i59pKThKfxnpqgmLuAZnmS24YbHNQDnRwqlunqGZqNV/tj qkkzKdHRdyXDBMNrasZgLHfCpo3ppYh/FB1YbzX4pXF0XiR9+4YPWdMF6LTPhOY0S1GoU/hLU7w PoFZBUa3Fs7RIPEhaGKyZ5JDhkbPFa+0Cn+/1zMziJlA== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs7.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165e7542ef30011e91.001 for ; Mon, 17 Sep 2018 11:39:38 +0000 X-Zone-Loop: b4910ad8e1d88161560fb3f1345b3cb29c46fa7bf0ba Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.ee (Postfix) with ESMTPSA id 77D0D128B5C2 for ; Mon, 17 Sep 2018 14:39:38 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1537184378; bh=3oEAMTEx7JYrh/jrP9GfTxYEVYdv2riKM0gC4kUmLrY=; h=Subject:To:References:From:Date:In-Reply-To; b=U1XqQE2XgttBcO5NT2pmyvTmnceTPHFMBJ1Ou5x6O1wV5818jN2EN3g0sguCxQoz4 nf+5WpTbP8zeiUrFBSseSxxOskofRe1rQbcyROHjSMoFu2vXtLudFxFTz6iEM+ubhd N8TndaTYnIJpX97NI0OLLS52isBnUgSpO+Pdq/uLFRPVZrtGIM3NL3IYucHX7/3cHh wc+a5WZ50es+nC4X9i/fUqybnFMu6JPQ3Er7v4Yme5DtiJR6yblv83nOHPSionEVXA 7EcgaI1U5s6OzuGsZjhgc6RowRz1wyS3ru+lAlYiyhMKLmF57pMh2j8DMos8wh7JQN JO2JhmuU0HV4w== To: jmap@ietf.org References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <4e152f15-e2be-5d71-13f4-4a709539573a@dot.ee> Date: Mon, 17 Sep 2018 11:39:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6086ABC019E8F4C149885EDD" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-3.152717, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.952717, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 11:39:44 -0000 This is a multi-part message in MIME format. --------------6086ABC019E8F4C149885EDD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 9/17/18 11:28 AM, Aki Tuomi wrote: > Or you implement debug logging in your client / server so that it can be > instructed to store the raw chatter in some log file? > > Aki Tuomi Have either of you implemented some server (be it IMAP, DAV+CalDAV etc) by spec and then discovered that none of the major client-side implementations work as they should and all require hours of trial and error with multiple hacks to properly work? Printing to syslog on production and deploying every time to test miniscule changes is a brain-dead way to develop, not to mention it only works if you have an Internet connection. Don't kid yourself that the implementations of tomorrow's standards will in any way be better than yesterday's. On 17.09.2018 14:26, Arnt Gulbrandsen wrote: > Maybe I misunderstand... what does requiring support for plain-HTTP > transport achieve compared to decrypting connections? > > Arnt Arnt, I answered that in my previous email, but if it's not clear, imagine, how would you get a certificate for 10.1.2.3 that iOS would accept? What if the client app comes with its own bundled CA roots? You won't get anything to decrypt in the first place. --------------6086ABC019E8F4C149885EDD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 9/17/18 11:28 AM, Aki Tuomi wrote:
Or you implement debug logging in your client / server so that it can be
instructed to store the raw chatter in some log file?

Aki Tuomi

Have either of you implemented some server (be it IMAP, DAV+CalDAV etc) by spec and then discovered that none of the major client-side implementations work as they should and all require hours of trial and error with multiple hacks to properly work? Printing to syslog on production and deploying every time to test miniscule changes is a brain-dead way to develop, not to mention it only works if you have an Internet connection. Don't kid yourself that the implementations of tomorrow's standards will in any way be better than yesterday's.

On 17.09.2018 14:26, Arnt Gulbrandsen wrote:

Maybe I misunderstand... what does requiring support for plain-HTTP
transport achieve compared to decrypting connections?

Arnt

Arnt, I answered that in my previous email, but if it's not clear, imagine, how would you get a certificate for 10.1.2.3 that iOS would accept? What if the client app comes with its own bundled CA roots? You won't get anything to decrypt in the first place.

--------------6086ABC019E8F4C149885EDD-- From nobody Mon Sep 17 04:47:06 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 BA9E0130E3D for ; Mon, 17 Sep 2018 04:47:04 -0700 (PDT) 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 (1024-bit key) header.d=neiseo.org header.b=pbjbNNB9; dkim=pass (1024-bit key) header.d=neiseo.org header.b=eOz40sT5 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 0YE8M15RZdQk for ; Mon, 17 Sep 2018 04:47:00 -0700 (PDT) Received: from forward100o.mail.yandex.net (forward100o.mail.yandex.net [37.140.190.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E101130E1B for ; Mon, 17 Sep 2018 04:47:00 -0700 (PDT) Received: from mxback15j.mail.yandex.net (mxback15j.mail.yandex.net [IPv6:2a02:6b8:0:1619::91]) by forward100o.mail.yandex.net (Yandex) with ESMTP id 39FD42A25FBD for ; Mon, 17 Sep 2018 14:46:57 +0300 (MSK) Received: from smtp4p.mail.yandex.net (smtp4p.mail.yandex.net [2a02:6b8:0:1402::15:6]) by mxback15j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id AVJIetNEDn-kvAiOE9j; Mon, 17 Sep 2018 14:46:57 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiseo.org; s=mail; t=1537184817; bh=eQIOwmI0P1WyiS1afVh7ka+AYlTcek9PTBChdfWj9yo=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=pbjbNNB9gRPHRVIgzCPMxXNrBQ+VY6PiCt/0nw4LOpg7rWDJr12RtqewRSRfpfTl3 fYz1qg+WUkiIw0QoJ7yNstKJUweSZjskEnVYeJpKX5GSDlid3ZDYoErOheL3qNuXeD vgRCVDiOaqVGRADWP9CZ4w4DBB3OIK/6X7RQUfpg= Received: by smtp4p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id OKucWYKQqo-kuwOjrxO; Mon, 17 Sep 2018 14:46:56 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiseo.org; s=mail; t=1537184816; bh=eQIOwmI0P1WyiS1afVh7ka+AYlTcek9PTBChdfWj9yo=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=eOz40sT5AKwKbGJTyzeQB0b8i3cqx8npTeOc+NLXlZP//Y9JMpZDhkWys/WOqIJZE 0VuFzvHF8+7VUrDs6wZbnYFJKm9rZfng4I67aYSBESIIiNwLi1PhWGV0X3e/eKE+Oo 6ohD23QgR2LWF/o6SbC37MDeSlRqRCb2q9qVa4qg= Authentication-Results: smtp4p.mail.yandex.net; dkim=pass header.i=@neiseo.org To: jmap@ietf.org References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> <4e152f15-e2be-5d71-13f4-4a709539573a@dot.ee> From: Nazim Can Bedir Message-ID: Date: Mon, 17 Sep 2018 14:47:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <4e152f15-e2be-5d71-13f4-4a709539573a@dot.ee> Content-Type: multipart/alternative; boundary="------------E5F700CDD0DDEDB8094DE646" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 11:47:05 -0000 This is a multi-part message in MIME format. --------------E5F700CDD0DDEDB8094DE646 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Instead of trying to get a certificate for 10.1.2.3, why don't    - create (let's say) dev3.uber-jmap-client.acme.com record with public IP address first    - get a certificate for it    - change DNS record to point 10.1.2.3    - use dev3.uber-jmap-client.acme.com instead of IP address in the client Yes, I understand what you are saying. But this kind of change (relaxing HTTPS requirement) could open an attack opportunity for bad guys. Regards, Nazim Can. On 17/09/2018 14:39, Andri Möll wrote: > On 9/17/18 11:28 AM, Aki Tuomi wrote: >> Or you implement debug logging in your client / server so that it can be >> instructed to store the raw chatter in some log file? >> >> Aki Tuomi > > Have either of you implemented some server (be it IMAP, DAV+CalDAV > etc) by spec and then discovered that none of the major client-side > implementations work as they should and all require hours of trial and > error with multiple hacks to properly work? Printing to syslog on > production and deploying every time to test miniscule changes is a > brain-dead way to develop, not to mention it only works if you have an > Internet connection. Don't kid yourself that the implementations of > tomorrow's standards will in any way be better than yesterday's. > > On 17.09.2018 14:26, Arnt Gulbrandsen wrote: >> Maybe I misunderstand... what does requiring support for plain-HTTP >> transport achieve compared to decrypting connections? >> >> Arnt > > Arnt, I answered that in my previous email, but if it's not clear, > imagine, how would you get a certificate for 10.1.2.3 that iOS would > accept? What if the client app comes with its own bundled CA roots? > You won't get anything to decrypt in the first place. > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------E5F700CDD0DDEDB8094DE646 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

Instead of trying to get a certificate for 10.1.2.3, why don't
   - create (let's say) dev3.uber-jmap-client.acme.com record with public IP address first
   - get a certificate for it
   - change DNS record to point 10.1.2.3
   - use dev3.uber-jmap-client.acme.com instead of IP address in the client

Yes, I understand what you are saying. But this kind of change (relaxing HTTPS requirement) could open an attack opportunity for bad guys.

Regards,
Nazim Can.

On 17/09/2018 14:39, Andri Möll wrote:
On 9/17/18 11:28 AM, Aki Tuomi wrote:
Or you implement debug logging in your client / server so that it can be
instructed to store the raw chatter in some log file?

Aki Tuomi

Have either of you implemented some server (be it IMAP, DAV+CalDAV etc) by spec and then discovered that none of the major client-side implementations work as they should and all require hours of trial and error with multiple hacks to properly work? Printing to syslog on production and deploying every time to test miniscule changes is a brain-dead way to develop, not to mention it only works if you have an Internet connection. Don't kid yourself that the implementations of tomorrow's standards will in any way be better than yesterday's.

On 17.09.2018 14:26, Arnt Gulbrandsen wrote:

Maybe I misunderstand... what does requiring support for plain-HTTP
transport achieve compared to decrypting connections?

Arnt

Arnt, I answered that in my previous email, but if it's not clear, imagine, how would you get a certificate for 10.1.2.3 that iOS would accept? What if the client app comes with its own bundled CA roots? You won't get anything to decrypt in the first place.


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--------------E5F700CDD0DDEDB8094DE646-- From nobody Mon Sep 17 05:10:08 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 C1029130E42 for ; Mon, 17 Sep 2018 05:10:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=zonevs.eu header.b=wLb6QoOM; dkim=pass (2048-bit key) header.d=srs2.zonevs.eu header.b=E3KQ+WWH; dkim=pass (2048-bit key) header.d=dot.ee header.b=AoD8tCfN 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 RL1QYwvYH-yi for ; Mon, 17 Sep 2018 05:10:04 -0700 (PDT) Received: from srs2.zonevs.eu (srs2.zonevs.eu [217.146.68.192]) (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 8B9AD130DD6 for ; Mon, 17 Sep 2018 05:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=M01loN1c3vhEzzbMBghqSyHRVz87jbuSSng5VDgnAZc=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=wLb6QoOMHasGcu4an0L8SMO81DRENOQ0Mbeo6LBAGsrR3nH96GWq+P7fvprNSFwNJg5MarPuy yMOV2/aQBbESpfDmGiTJEAX+vJLX44grFIhXvAMEs/l1YQd3XVVAYeruQqCP9GDw1w9+PT3RNOM Mb11nJY7SkVpgNfwnBu+I/G3zq8q/pcvghAiEAH0RwJsV+CnJnDy13LM+sWcnixQaU2C0d/LdAQ QmUgKuTU40/TeDygwXysuXi1Zvrd9htvu7T4TTGKDCGPuBVAYqB5l1bYYTtHqQ7Nqel/JFS53ao iDdLzsZ8lSWuXrUeFBzRc6TQiye2ANGacwU8wW2QhsWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs2.zonevs.eu; q=dns/txt; s=oct2016; bh=M01loN1c3vhEzzbMBghqSyHRVz87jbuSSng5VDgnAZc=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=E3KQ+WWHHVz34Gm2LGOOWUmAuYfu6v1wuUVFKMahyZ7CoNxqzX1EA9WA2EttM4h3LCpNemtp5 ishPISy0N0PxOvgrPhO7oB+lerMNXbFYhLUJpO7GRzWpE2Ghzs6j93vp2IzFK8MGK/EGZGB113P kPZ//ZExAFOCqh2OzlmPEVdEe831zGyePhGzneLKQxh6VWCHwt84z/VeGTBf+dEFZW5ie7yJMDv fYBEG2pYwVA+/kr7029MKxaw/iRzoW4/Zgl6r1ZguxaRsl6KqszSMvuJ8LbP1hM0YEeXRpdc32h GC6bCc06+Hsqq3xfCcGmXcvcUcnmvOO27pAKR+XBTn7w== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs2.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165e76ff1810001e91.001 for ; Mon, 17 Sep 2018 12:09:57 +0000 X-Zone-Loop: a8668e16c793e53e6b8b2fc90e7f7b8cda519fca3e8c Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.ee (Postfix) with ESMTPSA id 8150D128B5D2 for ; Mon, 17 Sep 2018 15:09:57 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1537186197; bh=Lh1/K1SmBuE4t5n6FQfC8ozD+YSB+X62bdwdtqbzCqM=; h=Subject:To:References:From:Date:In-Reply-To; b=AoD8tCfNk7s1salnlzb7sR70xf0YwR/tDFnXLoyz3ueFlkQaAI3rferizacjLUoEI qjRrD5dlhRRZ0ct+267+T3z5wWVmk5OcC3VVsSdyyj6ma1nN9VIUWstaEBEJ5i1QyR q8ypTOqkzH+NfErcSd4NpFXcmG/zb6lhBBRgDLJCntIOD6VVKRkhHD974+hoeshWeP qOsyvB2SaX2Rzk3P4/S7W2MeD20EfcPWusHXj7GR8U3od49WrPpGcnnl4BjZLIbqom sOwtKMCOEhtFILinJYwsXne0S1IfHjcP0edltK2z/9Kn9CSpWaQMJP9Aw6rBICUdh7 DK7TllkBi5uLQ== To: jmap@ietf.org References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> <4e152f15-e2be-5d71-13f4-4a709539573a@dot.ee> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <0f359f71-fdb7-bbe6-7807-66adc3936321@dot.ee> Date: Mon, 17 Sep 2018 12:09:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0703E5C255CFDDBEDAF67C3C" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.144816, required=15, tests=[HFILTER_HOSTNAME_5=3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.944816, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 12:10:08 -0000 This is a multi-part message in MIME format. --------------0703E5C255CFDDBEDAF67C3C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I was waiting for someone to offer that solution. ^_^ While doable, quite a pain in the ass. It requires you have access to the router _and_ that the router has been "jailbroken" to run a DNS server with which you can overwrite public domains. If not, you're again required to have an always-on Internet connection to just write some code by yourself. Having to solve a self-imposed development-problem is just a facepalm IMO. I'd much rather avoid the problem in the first place. > But this kind of change (relaxing HTTPS requirement) could open an > attack opportunity for bad guys. A decent warned override method or a toggle in the advanced settings of a client app is entirely sufficient to permit reasonable development and prevent accidental insecure connections. As said, something every mail/calendar app today already provides. On 9/17/18 11:47 AM, Nazim Can Bedir wrote: > > Hi, > > Instead of trying to get a certificate for 10.1.2.3, why don't >    - create (let's say) dev3.uber-jmap-client.acme.com record with > public IP address first >    - get a certificate for it >    - change DNS record to point 10.1.2.3 >    - use dev3.uber-jmap-client.acme.com instead of IP address in the > client > > Yes, I understand what you are saying. But this kind of change > (relaxing HTTPS requirement) could open an attack opportunity for bad > guys. > > Regards, > Nazim Can. > > On 17/09/2018 14:39, Andri Möll wrote: >> On 9/17/18 11:28 AM, Aki Tuomi wrote: >>> Or you implement debug logging in your client / server so that it can be >>> instructed to store the raw chatter in some log file? >>> >>> Aki Tuomi >> >> Have either of you implemented some server (be it IMAP, DAV+CalDAV >> etc) by spec and then discovered that none of the major client-side >> implementations work as they should and all require hours of trial >> and error with multiple hacks to properly work? Printing to syslog on >> production and deploying every time to test miniscule changes is a >> brain-dead way to develop, not to mention it only works if you have >> an Internet connection. Don't kid yourself that the implementations >> of tomorrow's standards will in any way be better than yesterday's. >> >> On 17.09.2018 14:26, Arnt Gulbrandsen wrote: >>> Maybe I misunderstand... what does requiring support for plain-HTTP >>> transport achieve compared to decrypting connections? >>> >>> Arnt >> >> Arnt, I answered that in my previous email, but if it's not clear, >> imagine, how would you get a certificate for 10.1.2.3 that iOS would >> accept? What if the client app comes with its own bundled CA roots? >> You won't get anything to decrypt in the first place. >> >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------0703E5C255CFDDBEDAF67C3C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I was waiting for someone to offer that solution. ^_^ While doable, quite a pain in the ass. It requires you have access to the router _and_ that the router has been "jailbroken" to run a DNS server with which you can overwrite public domains. If not, you're again required to have an always-on Internet connection to just write some code by yourself. Having to solve a self-imposed development-problem is just a facepalm IMO. I'd much rather avoid the problem in the first place.

But this kind of change (relaxing HTTPS requirement) could open an attack opportunity for bad guys.
A decent warned override method or a toggle in the advanced settings of a client app is entirely sufficient to permit reasonable development and prevent accidental insecure connections. As said, something every mail/calendar app today already provides.

On 9/17/18 11:47 AM, Nazim Can Bedir wrote:

Hi,

Instead of trying to get a certificate for 10.1.2.3, why don't
   - create (let's say) dev3.uber-jmap-client.acme.com record with public IP address first
   - get a certificate for it
   - change DNS record to point 10.1.2.3
   - use dev3.uber-jmap-client.acme.com instead of IP address in the client

Yes, I understand what you are saying. But this kind of change (relaxing HTTPS requirement) could open an attack opportunity for bad guys.

Regards,
Nazim Can.

On 17/09/2018 14:39, Andri Möll wrote:
On 9/17/18 11:28 AM, Aki Tuomi wrote:
Or you implement debug logging in your client / server so that it can be
instructed to store the raw chatter in some log file?

Aki Tuomi

Have either of you implemented some server (be it IMAP, DAV+CalDAV etc) by spec and then discovered that none of the major client-side implementations work as they should and all require hours of trial and error with multiple hacks to properly work? Printing to syslog on production and deploying every time to test miniscule changes is a brain-dead way to develop, not to mention it only works if you have an Internet connection. Don't kid yourself that the implementations of tomorrow's standards will in any way be better than yesterday's.

On 17.09.2018 14:26, Arnt Gulbrandsen wrote:

Maybe I misunderstand... what does requiring support for plain-HTTP
transport achieve compared to decrypting connections?

Arnt

Arnt, I answered that in my previous email, but if it's not clear, imagine, how would you get a certificate for 10.1.2.3 that iOS would accept? What if the client app comes with its own bundled CA roots? You won't get anything to decrypt in the first place.


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


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--------------0703E5C255CFDDBEDAF67C3C-- From nobody Mon Sep 17 06:20:16 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 BA2BE130E68 for ; Mon, 17 Sep 2018 06:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=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=icloud.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 ogopIrHcg7JJ for ; Mon, 17 Sep 2018 06:20:12 -0700 (PDT) Received: from st13p97im-ztdg18301101.me.com (st13p97im-ztdg18301101.me.com [17.41.193.160]) (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 D7BD4130E3C for ; Mon, 17 Sep 2018 06:20:12 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p97im-ztdg18301101.me.com by st13p97im-ztdg18301101.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PF700000AI0NQ00@st13p97im-ztdg18301101.me.com> for jmap@ietf.org; Mon, 17 Sep 2018 13:20:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1537190412; bh=m6TsdOunbKHykHoK6IDs9DOmwfD0gpsiuhN1d/Go5JU=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=gJl4MCGlU0UJbpvy4p2bNJ2yyf5EHx2+wH62s5ebc0WkEFje/cXDHU39hIvVl4Ehn Wd4cwen5V9OUGzuIU77W1umQghWS6UUxbevYXvy6p3HG6P1/GGapw6Ine9lIxxLVm+ TePAcVx7gqZjfGPAPZpaDlba1tLwu6CGQNDiHXXeWUSB8OWmxuhmTAez7lHdQrybGB DxcVP/giZw00aBu9L2I5TwAKtmdI61xXU+qY1TlGrxFOaRL5kABoNwwNxOed3kXymb bbDHnyd71KPi/iXPFOwD9/53EhAMB2XbdGxvfTFVClMeN6HGNJD9aHJyZmsGsWPKjg ZcWUCUBq0YN0w== Received: from icloud.com ([127.0.0.1]) by st13p97im-ztdg18301101.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PF700D5YBPL2V30@st13p97im-ztdg18301101.me.com>; Mon, 17 Sep 2018 13:20:11 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=714 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809170137 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-17_05:,, signatures=0 Content-type: multipart/alternative; boundary=Apple-Mail-789B6CCA-7E8C-4F35-9A4F-AAEF95803493 MIME-version: 1.0 (1.0) From: Sudi X-Mailer: iPhone Mail (16A5366a) In-reply-to: <0f359f71-fdb7-bbe6-7807-66adc3936321@dot.ee> Date: Mon, 17 Sep 2018 06:20:09 -0700 Cc: jmap@ietf.org Content-transfer-encoding: 7bit Message-id: References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> <4e152f15-e2be-5d71-13f4-4a709539573a@dot.ee> <0f359f71-fdb7-bbe6-7807-66adc3936321@dot.ee> To: =?utf-8?Q?Andri_M=C3=B6ll?= Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 13:20:16 -0000 --Apple-Mail-789B6CCA-7E8C-4F35-9A4F-AAEF95803493 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This should work?=20 https://www.charlesproxy.com/ -Sudi =F0=9F=93=B2=20 > On Sep 17, 2018, at 5:09 AM, Andri M=C3=B6ll wrote: >=20 > I was waiting for someone to offer that solution. ^_^ While doable, quite a= pain in the ass. It requires you have access to the router _and_ that the r= outer has been "jailbroken" to run a DNS server with which you can overwrite= public domains. If not, you're again required to have an always-on Internet= connection to just write some code by yourself. Having to solve a self-impo= sed development-problem is just a facepalm IMO. I'd much rather avoid the pr= oblem in the first place. >=20 >> But this kind of change (relaxing HTTPS requirement) could open an attack= opportunity for bad guys. > A decent warned override method or a toggle in the advanced settings of a c= lient app is entirely sufficient to permit reasonable development and preven= t accidental insecure connections. As said, something every mail/calendar ap= p today already provides. >> On 9/17/18 11:47 AM, Nazim Can Bedir wrote: >> Hi, >>=20 >> Instead of trying to get a certificate for 10.1.2.3, why don't >> - create (let's say) dev3.uber-jmap-client.acme.com record with public= IP address first >> - get a certificate for it >> - change DNS record to point 10.1.2.3 >> - use dev3.uber-jmap-client.acme.com instead of IP address in the clie= nt >>=20 >> Yes, I understand what you are saying. But this kind of change (relaxing H= TTPS requirement) could open an attack opportunity for bad guys. >>=20 >> Regards, >> Nazim Can. >>=20 >>> On 17/09/2018 14:39, Andri M=C3=B6ll wrote: >>>> On 9/17/18 11:28 AM, Aki Tuomi wrote: >>>> Or you implement debug logging in your client / server so that it can b= e >>>> instructed to store the raw chatter in some log file? >>>>=20 >>>> Aki Tuomi >>> Have either of you implemented some server (be it IMAP, DAV+CalDAV etc) b= y spec and then discovered that none of the major client-side implementation= s work as they should and all require hours of trial and error with multiple= hacks to properly work? Printing to syslog on production and deploying ever= y time to test miniscule changes is a brain-dead way to develop, not to ment= ion it only works if you have an Internet connection. Don't kid yourself tha= t the implementations of tomorrow's standards will in any way be better than= yesterday's. >>>=20 >>>> On 17.09.2018 14:26, Arnt Gulbrandsen wrote: >>>> Maybe I misunderstand... what does requiring support for plain-HTTP >>>> transport achieve compared to decrypting connections? >>>>=20 >>>> Arnt >>> Arnt, I answered that in my previous email, but if it's not clear, imagi= ne, how would you get a certificate for 10.1.2.3 that iOS would accept? What= if the client app comes with its own bundled CA roots? You won't get anythi= ng to decrypt in the first place. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Jmap mailing list >>> Jmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/jmap >>=20 >>=20 >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --Apple-Mail-789B6CCA-7E8C-4F35-9A4F-AAEF95803493 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This should work? 
https://www.charlesproxy.com/
-Sudi
=F0=9F=93=B2=  

On Sep 17, 2018, at 5:09 AM, A= ndri M=C3=B6ll <andri@dot.ee> wrot= e:

=20 =20 =20

I was waiting for someone to offer that solution. ^_^ While doable, quite a pain in the ass. It requires you have access to the router _and_ that the router has been "jailbroken" to run a DNS server with which you can overwrite public domains. If not, you're again required to have an always-on Internet connection to just write some code by yourself. Having to solve a self-imposed development-problem is just a facepalm IMO. I'd much rather avoid the problem in the first place.

But this kind of change (relaxing HTTPS requirement) could open an attack opportunity for bad guys. A decent warned override method or a toggle in the advanced settings of a client app is entirely sufficient to permit reasonable development and prevent accidental insecure connections. As said, something every mail/calendar app today already provides.

On 9/17/18 11:47 AM, Nazim Can Bedir wrote:

Hi,

Instead of trying to get a certificate for 10.1.2.3, why don't
   - create (let's say) dev3.uber-jmap-client.acme.com record with public IP address first
   - get a certificate for it
   - change DNS record to point 10.1.2.3
   - use dev3.uber-jmap-client.acme.com instead of IP address in the client

Yes, I understand what you are saying. But this kind of change (relaxing HTTPS requirement) could open an attack opportunity for bad guys.

Regards,
Nazim Can.

On 17/09/2018 14:39, Andri M=C3=B6ll wrote:
On 9/17/18 11:28 AM, Aki Tuomi wrote:
Or you implement debug logg=
ing in your client / server so that it can be
instructed to store the raw chatter in some log file?

Aki Tuomi

Hav= e either of you implemented some server (be it IMAP, DAV+CalDAV etc) by spec and then discovered that none of the major client-side implementations work as they should and all require hours of trial and error with multiple hacks to properly work? Printing to syslog on production and deploying every time to test miniscule changes is a brain-dead way to develop, not to mention it only works if you have an Internet connection. Don't kid yourself that the implementations of tomorrow's standards will in any way be better than yesterday's.

On 17.09.2018 14:26, Arnt Gul=
brandsen wrote:

Maybe I misunderstand... wh=
at does requiring support for plain-HTTP
transport achieve compared to decrypting connections?

Arnt

Arnt, I answered that in my previous email, but if it's not clear, imagine, how would you get a certificate for 10.1.2.3 that iOS would accept? What if the client app comes with its own bundled CA roots? You won't get anything to decrypt in the first place.


_____________________________=
__________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jm=
ap


_______________________________=
________________
Jmap mailing list
Jmap@iet=
f.org
https://www.ietf.org/mailman/listinfo/jmap
=20
________= _______________________________________
Jmap mailing list
Jmap@ietf.org
<= span>https://www.ietf= .org/mailman/listinfo/jmap
= --Apple-Mail-789B6CCA-7E8C-4F35-9A4F-AAEF95803493-- From nobody Mon Sep 17 07:10:01 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 D4CF4130E6C for ; Mon, 17 Sep 2018 07:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfI-eO6y60sA for ; Mon, 17 Sep 2018 07:09:56 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 2A6121286D9 for ; Mon, 17 Sep 2018 07:09:56 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id t5-v6so15368881qtn.3 for ; Mon, 17 Sep 2018 07:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eAFu2rUi9ErKHJRv6A3JG5/X7JzWhF+fuxLy2UGN16A=; b=OCm8I8AzhYKEyCBHkPr6brGiDCor8pkElOpaWVoLMOqcKdUwdwtzvQ5UOo87d9BI+v 9LB27g+dSp2yNq7Wpnw//KKmFrAXJb+CUJVzSqivdDS9QNBacWoWHsm1Eq6uMU2aUJPG l53G0VonoCR39bMnLYyLXBZZpzodGWI1ppSkKxPzuWlOuUwcfLBtadaVY2qJPY8j+xPs VEOHHKlBjNHMODmtNI7eevK2XG2OBwji0DAcLUEqCp2UTERw/PHcAku+iekOWYD60GaP tIhwVZEoDeDUG9TN4sSDNlAMi0R2y4bsCSoBtgtrDCWYZQdCpAtcYOcLgKdqzw/sM3Zg ltHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eAFu2rUi9ErKHJRv6A3JG5/X7JzWhF+fuxLy2UGN16A=; b=DhcXdot+ftK4UBsjF4HIVg3i9K8KUnW0m18JMbCQ0n58hb8HnA0CbZqI5tfkBFI7Xq uy6YWTq/hGmI5b5LZqmU2nIl99Z1ExlvyIlIjiRj/HtafQvBhMsRJIKDfAK2a0tqjyIP jKqtEgXoMJ9XIie6Bysbg7s0ksyMyNIuSkCoYn6tM1k0Z6eqPfKYJx5EPo5AqtjW971p 4BqCLYr/b4ZuLl6hTX5iIDF5M1efcOozA0opHYarhim24ak8bHExUf5UAuBAYrxLnoyl ltVl+n2Q20nSRqmNmvoJQ5+uRaNvgaFdBX0n4RCrbKSNvnWkBncg3AhJqFK56RRWdMQK 3tOQ== X-Gm-Message-State: APzg51CijFyBLC6RK+XwVMgF1MDPsvXoK/Rm+V7JNp+bZkW67lOr/yUc bI+41Wp+zM0NfqKq1EZDlwncDDbAu3g= X-Google-Smtp-Source: ANB0VdbAW/FSFHFdQnn3Ydne8x/xdYMDoaj+1DUOTUvNT/f+7MuYXeL/9fraUXRa07gYpRAnwWaTgA== X-Received: by 2002:aed:26e7:: with SMTP id q94-v6mr18025889qtd.37.1537193395143; Mon, 17 Sep 2018 07:09:55 -0700 (PDT) Received: from [10.0.100.12] (c-73-167-89-221.hsd1.ma.comcast.net. [73.167.89.221]) by smtp.gmail.com with ESMTPSA id f13-v6sm8056212qth.62.2018.09.17.07.09.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 07:09:53 -0700 (PDT) From: Ted Lemon Message-Id: <6247ED59-17F9-4AFE-AB71-FF024681BD2D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D1296091-1827-448A-8FD2-ADE56DDEC665" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 17 Sep 2018 10:09:52 -0400 In-Reply-To: <0f359f71-fdb7-bbe6-7807-66adc3936321@dot.ee> Cc: jmap@ietf.org To: =?utf-8?Q?Andri_M=C3=B6ll?= References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> <4e152f15-e2be-5d71-13f4-4a709539573a@dot.ee> <0f359f71-fdb7-bbe6-7807-66adc3936321@dot.ee> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 14:09:59 -0000 --Apple-Mail=_D1296091-1827-448A-8FD2-ADE56DDEC665 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 17, 2018, at 8:09 AM, Andri M=C3=B6ll wrote: > A decent warned override method or a toggle in the advanced settings = of a client app is entirely sufficient to permit reasonable development = and prevent accidental insecure connections. As said, something every = mail/calendar app today already provides. Yes, and these are routinely used to phish or snoop on naive users. = There is no technical reason why you should need to be able to force a = downgrade. It's just the debugging flow you're comfortable with. = That's understandable, but hardly reason enough to make the protocol = insecure. E.g., if you had only HTTPS CalDAV, which I think is what = you should only have, then you would indeed have to work harder to debug = the problem. And that would be okay. We had a very long discussion about this in the TLS WG over the past = year, and the conclusion we reached was "no, we're not going to break = TLS to make debugging easier." --Apple-Mail=_D1296091-1827-448A-8FD2-ADE56DDEC665 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Sep 17, 2018, at 8:09 AM, Andri M=C3=B6ll <andri@dot.ee> = wrote:
A decent warned override method or a toggle in the advanced = settings of a client app is entirely sufficient to permit reasonable = development and prevent accidental insecure connections. As said, = something every mail/calendar app today already = provides.

Yes, and these are routinely used to phish or snoop on naive = users.   There is no technical reason why you should need to be = able to force a downgrade.   It's just the debugging flow you're = comfortable with.   That's understandable, but hardly reason enough = to make the protocol insecure.   E.g., if you had only HTTPS = CalDAV, which I think is what you should only have, then you would = indeed have to work harder to debug the problem.   And that would = be okay.

We = had a very long discussion about this in the TLS WG over the past year, = and the conclusion we reached was "no, we're not going to break TLS to = make debugging easier."

= --Apple-Mail=_D1296091-1827-448A-8FD2-ADE56DDEC665-- From nobody Mon Sep 17 07:37:38 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 8F831128CF3 for ; Mon, 17 Sep 2018 07:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Vqtopg0aeMhJ for ; Mon, 17 Sep 2018 07:37:34 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8ED124C04 for ; Mon, 17 Sep 2018 07:37:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0AD00A5CB9F4; Mon, 17 Sep 2018 10:37:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snSw6HzfMx9B; Mon, 17 Sep 2018 10:37:33 -0400 (EDT) Received: from [17.44.178.182] (unknown [17.44.178.182]) by daboo.name (Postfix) with ESMTPSA id EC962A5CB9E3; Mon, 17 Sep 2018 10:37:32 -0400 (EDT) Date: Mon, 17 Sep 2018 10:35:36 -0400 From: Cyrus Daboo To: =?UTF-8?Q?Andri_M=C3=B6ll?= , jmap@ietf.org Message-ID: In-Reply-To: <4e152f15-e2be-5d71-13f4-4a709539573a@dot.ee> References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> <4e152f15-e2be-5d71-13f4-4a709539573a@dot.ee> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1027 Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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: Mon, 17 Sep 2018 14:37:37 -0000 Hi Andri, --On September 17, 2018 at 11:39:37 AM +0000 Andri M=C3=B6ll = wrote: > Arnt, I answered that in my previous email, but if it's not clear, > imagine, how would you get a certificate for 10.1.2.3 that iOS would > accept? On this one issue: you can use Apple's Configurator.app (available on Mac=20 app store) to install a trusted root certificate on an iOS device. What I=20 typically do is: 1) Use Keychain.app on macOS to create a "Certificate Authority" = certificate 2) Export that cert as a PEM file 3) Use Keychain.app to create a "leaf" certificate signed by the CA cert 4) Install the leaf in the server (and include the CA cert in the server's=20 "chain" file) 5) Use Configurator.app to create a certificate profile containing the CA=20 cert 6) Use Configurator.app to install the profile on an iOS device Steps 1-5 only need to be done once, then you can install on as many=20 devices as you want. I have used this process for both development and for my personal=20 "production" server. --=20 Cyrus Daboo From nobody Mon Sep 17 22:18:47 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 992321200D6 for ; Mon, 17 Sep 2018 22:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueAMCgfMCgV2 for ; Mon, 17 Sep 2018 22:18:44 -0700 (PDT) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 D660412008A for ; Mon, 17 Sep 2018 22:18:43 -0700 (PDT) Received: by mail-yw1-xc35.google.com with SMTP id l9-v6so278708ywc.11 for ; Mon, 17 Sep 2018 22:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UDbRssmVCWu9aiysKKo5DWr9KCVQjGbSNf/YNy0BeWE=; b=t7AhKbIcLIcKCHIfhvGr07DidEaL2b1wzFw4AmuXuMM+0d5irUkxG4a4nMs0h1us8h uKYrzFVfIY1i6cQdhVrL1x8LlCjfCaD/yTaHAL7Qdb7SoeWwKVSrz46x4UayC8U2bbaa ABmGbCNoGFMszP+6I+JpryOgACK7vyygvfIZ2qLalG6rG93/9bvaPzO0IzTh4NOqJytG AWs7v6sFuwKM78U/+pjo+Hq3llwCictiM6QxkAeal37z4lvIREjs23Y96sj0M1Le3fdi TNg0rymxsM1fHISpwQwbxvuYYZQkEJih+7SVmhv3dnfotC7mEL7C8EvceC7gAVN9XKFp 90bw== 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=UDbRssmVCWu9aiysKKo5DWr9KCVQjGbSNf/YNy0BeWE=; b=LuvyKZDg6/y2HFAQqCPZ2GYbJZv/2NTJdXj0kUNIj7edKHhsrZjPt2NDCDPiCv0j4R LgepRcp7QUPkSbAFdXWhw1ejWf7PmEmvXZnDPti+UUV3BXDfy+uBHc8WcMk/RoBdRF0P 2knJF/2g+neg/tBXNNDnFFm55vJKpSeQKI/q9bgvOSMKVj/gfcYrgGunOHRRXIH2eZJU yK5xebrtAvahyGgzyCzuzSvMdGfOOeR9UAi3MdiWaL9LEYBzSZH/va5LhusDaJmpNoh4 ELB9sh6fhcONoUMNooYFvAtSJcGPpchoXwNYhblIBI8syZRSbuhEXclkodIKJPFRQ2lL uHdg== X-Gm-Message-State: APzg51C9YzzSszOVmlqSkcANTadQMDrHLVO/uN80ahkOTwoKvZobgtnS A3gAX8+kZZSMBBo92r0UQzvKstVjBLaUppO6UVQhUpg= X-Google-Smtp-Source: ANB0VdYWVK/Ityuy3lvv4V5RpYLXb45vgFWbi3ET7U/vtKf+mDpQHCAyRHSQiRiXI0+gMlWL4OvqCONHbxKnGyiSpd4= X-Received: by 2002:a0d:d243:: with SMTP id u64-v6mr12006495ywd.109.1537247922591; Mon, 17 Sep 2018 22:18:42 -0700 (PDT) MIME-Version: 1.0 References: <76c4093a-1fbc-ec3e-39f8-c65824e9e07c@dot.ee> <62afd620-15db-415b-a6ae-0f8343cb8a81@gulbrandsen.priv.no> <55e70827-1ec5-7c20-fccf-855e42855e9b@dot.ee> <7e4cae54-d610-49e5-bf99-cf32f13d4af1@gulbrandsen.priv.no> <4e152f15-e2be-5d71-13f4-4a709539573a@dot.ee> <0f359f71-fdb7-bbe6-7807-66adc3936321@dot.ee> <6247ED59-17F9-4AFE-AB71-FF024681BD2D@fugue.com> In-Reply-To: <6247ED59-17F9-4AFE-AB71-FF024681BD2D@fugue.com> From: Brandon Long Date: Mon, 17 Sep 2018 22:18:30 -0700 Message-ID: To: Ted Lemon Cc: andri@dot.ee, jmap@ietf.org Content-Type: multipart/alternative; boundary="0000000000005c305505761e6c66" Archived-At: Subject: Re: [Jmap] Unconditional HTTPS requirement and server development debugging 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, 18 Sep 2018 05:18:46 -0000 --0000000000005c305505761e6c66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 17, 2018 at 7:10 AM Ted Lemon wrote: > On Sep 17, 2018, at 8:09 AM, Andri M=C3=B6ll wrote: > > A decent warned override method or a toggle in the advanced settings of a > client app is entirely sufficient to permit reasonable development and > prevent accidental insecure connections. As said, something every > mail/calendar app today already provides. > > > Yes, and these are routinely used to phish or snoop on naive users. > There is no technical reason why you should need to be able to force a > downgrade. It's just the debugging flow you're comfortable with. That= 's > understandable, but hardly reason enough to make the protocol insecure. > E.g., if you had only HTTPS CalDAV, which I think is what you should only > have, then you would indeed have to work harder to debug the problem. A= nd > that would be okay. > > We had a very long discussion about this in the TLS WG over the past year= , > and the conclusion we reached was "no, we're not going to break TLS to ma= ke > debugging easier." > +1. You're making things less secure for millions of users in order to make your life a bit easier. Brandon --0000000000005c305505761e6c66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Sep 17, 2018 at 7:10 AM Ted Lemon <mellon@fugue.com> wrote:
On Sep 17, 2= 018, at 8:09 AM, Andri M=C3=B6ll <andri@dot.ee> wrote:
= A decent warned override method or a toggle in the advance= d settings of a client app is entirely sufficient to permit reasonable deve= lopment and prevent accidental insecure connections. As said, something eve= ry mail/calendar app today already provides.

Yes, and these are routinely used to phish or snoop on naive user= s. =C2=A0 There is no technical reason why you should need to be able to fo= rce a downgrade. =C2=A0 It's just the debugging flow you're comfort= able with. =C2=A0 That's understandable, but hardly reason enough to ma= ke the protocol insecure. =C2=A0 E.g., if you had only HTTPS CalDAV, which = I think is what you should only have, then you would indeed have to work ha= rder to debug the problem. =C2=A0 And that would be okay.

We had a very long discussion about this in the TLS WG over the pas= t year, and the conclusion we reached was "no, we're not going to = break TLS to make debugging easier."

=
+1.=C2=A0 You're making things less secure for millions of u= sers in order to make your life a bit easier.

Bran= don=C2=A0
--0000000000005c305505761e6c66-- From nobody Tue Sep 18 21:47:28 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 31247130F20 for ; Tue, 18 Sep 2018 21:47:27 -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=nB4Btvdh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SGHKm4rc 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 whNdcqSmnwRb for ; Tue, 18 Sep 2018 21:47:25 -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 49E88130DE0 for ; Tue, 18 Sep 2018 21:47:25 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 617DF21F50 for ; Wed, 19 Sep 2018 00:47:24 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Wed, 19 Sep 2018 00:47:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:message-id:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=XvmwjRaH2F/38fsT/ c4bcfHgRIB0v4fZWpCvCVMd2gg=; b=nB4Btvdh1jAFNnRFexUPsTwj/xpOg2Tvj w8kLfuKZgPlT0jbwSZi9dDYZVyilu9IIEtcYRucW/n2lnoJf3FRXvsLFUYZJ1DKF yzCwKk/Um7zj1VBPVC7aC8Q06r+BmSFs8JlPvmPpZtWKXO7HJqrz5aG2wShhl1Ot 6X5tCCBM3tWj0N2tqYFihfxvlSzgpnfOecQAa05MVNqD/fNJYGPzeTsrrMOli76n mXd8xUJ+rIhseGfuo9zROG+jNO8g65Nx+19IzyDNX67tZBtYd2GBfcUcIqZBpJ3G jyhJmEvW8nW1YuawZIALmGgQF6gaHkpxRzyHYx24V3csQFieJmNaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=XvmwjRaH2F/38f sT/c4bcfHgRIB0v4fZWpCvCVMd2gg=; b=SGHKm4rcvaJlsWIz7slLvITadxNKTc Tjfaw6lAdZwB/jnkKioLJIrYusnILPnrhFiSW0uKdrizhNPXDO0ML4Q92JmPPiCe qqrGykv2Ua4P4ctmaYluS4ieqfojMYrC8wCM9QuUpAWK5J+78kS32jE6VgFDKkVr x0UeSuXmt51QV/2AtbZggunvVgBPL7sSBokS6QmvJQF6101sIR5Wyf5Wcfaimri+ PrQZfJKTIMxHeX7Z3jSjxYAvCmGvIi7Xi6lGzyFSUbdl2Ad6MMIUokMMKU2JUxTR Z8CnmE83+MI3BI7E5FjYe5skSbWYASW66wbXzqn1vDY6H6wfTZuZb0tA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B6665E7A2; Wed, 19 Sep 2018 00:47:23 -0400 (EDT) Message-Id: <7ba36325-c27f-432b-af23-d38515cdfb68@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-505-gda119d7-fmnext-20180918v4 x-jmap-identity-id: 56629417 Date: Wed, 19 Sep 2018 00:47:23 -0400 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=5545b05bb58249969a8e72bd0e1d97de Archived-At: Subject: [Jmap] jmap-core implementation feedback: Issue #260 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: Wed, 19 Sep 2018 04:47:27 -0000 --5545b05bb58249969a8e72bd0e1d97de Content-Type: text/plain While implementing a Foo/copy handler (actually for StorageNode, aka Files) I've been looking over the state handling, and based on that I realised that copy is sorely lacking in state management. I've opened https://github.com/jmapio/jmap/issues/260 for this. Since we're in working group last call, this is exactly the kind of feedback we'd love from other people impementing as well. And I'd welcome any comments on whether I've missed anything here. (I went ahead and created https://github.com/jmapio/jmap/issues/261 as well for Email/import) Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --5545b05bb58249969a8e72bd0e1d97de Content-Type: text/html Content-Transfer-Encoding: quoted-printable
While implementing a Foo/copy handler (actually for Storag= eNode, aka Files) I've been looking over the state handling, and based o= n that I realised that copy is sorely lacking in state management.

I've opened https://github.com/jmapio/jmap/issues/260 for this.  Since = we're in working group last call, this is exactly the kind of feedback w= e'd love from other people impementing as well.  And I'd welcome an= y comments on whether I've missed anything here.

(I went = ahead and created = https://github.com/jmapio/jmap/issues/261 as well for Email/import)<= br>

Cheers,

Br= on.

--
&= nbsp; Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

--5545b05bb58249969a8e72bd0e1d97de--