From nobody Sun Oct 1 16:50:17 2017 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 1E58A1342CA for ; Sun, 1 Oct 2017 16:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=k176FC+x; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IRw3DPdp 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 Uo2NQ5qep55Y for ; Sun, 1 Oct 2017 16:50:13 -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 9142D1321A0 for ; Sun, 1 Oct 2017 16:50:13 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id C331920C90 for ; Sun, 1 Oct 2017 19:50:12 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 01 Oct 2017 19:50:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=O/2UM5IaDv02LlvwGG/wO3rhi1jjJCdmJR6Oq9RM7 /E=; b=k176FC+xwoCVbZfJPy5bMnMyVHg/m605A5bKzzXoGgjDCXm/npyZuyxXp jWdCDvA69wSam57wkXOtaaD86MaWfrk9X45P/vqqGsP+rzAaMrsf35i6aSCgSLAo fBB9WNH6RFfzEGNMxUNzNaESApyHmrVDr8JRVws1WIUjYMUH8cqTrkfWaqiIdBRU W04BLzQInv6pHs9PC2uRDPK8Z3whE6suN+F1mt1GjVHBTgfHL/xNHOtS9q42zQWg 2v0PjESXNC0uH4Nsx9tsnpDTGaps0fP9cZA9x9vwIliKEe1Am71C872xAF02Mbiy iZldnkKnOZT3bCWAe2P8AZcRM8ZTw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=O/2UM5IaDv02LlvwGG/wO3rhi1jjJ CdmJR6Oq9RM7/E=; b=IRw3DPdpO6kDS/PQlWyUeQ8Cdk9R+66BLG9LvJZGfPQi1 fbHRwXVXzbeVpQAEx4+ct4hmyUy66t7icKFnKC+tNZjUIuH8JTbMV+Zvz3NvjZEz 2JA5RUz9I1KBBYqBmSSEEMaRgJgf3cJG61vlG5IHD5kO0PKjrZo5GAPy7SzBlbEh YsSYYLd7WhnPDLwoSj+w76EsBonyiLXRYsxrl/Kmu554y4qPlOA/I8YG2/AJ8YpW 4H+eUJPZ9yc91i42T1KZYzULspwJoD74yYSamBJ3ByWuab2DUO+i+eTwp8Bp+2wf 4JLbA14x1H5R3+rvdoewwRwTeUmEHKgqSu+TtxDMQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 20DA8E254E; Sun, 1 Oct 2017 19:50:12 -0400 (EDT) Message-Id: <1506901811.676009.1124417296.5EB56E32@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15069018126760091" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5f0bf376 Date: Mon, 02 Oct 2017 10:50:11 +1100 Archived-At: Subject: [Jmap] Using the result of one method as a subsequent method argument X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 23:50:16 -0000 This is a multi-part message in MIME format. --_----------=_15069018126760091 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi all, This week I have been doing a lot of copy editing to remove a huge amount of duplicative text, which made the spec harder to read, and more likely to contain inconsistencies between methods. My goal is that the JMAP Mail spec should just be: 1. The data type definitions 2. Which standard method types can be used with each data type (e.g. the Thread object is not mutable directly by the client so there is no setThreads method). 3. Any changes to the standard method for that particular type (extra arguments etc.)This makes the spec *much* shorter, more understandable = and easier to implement. Doing this also makes it easier to see where methods for a particular type deviate from the =E2=80=9Cstandard=E2=80=9D JMAP get/set ca= lls. As I looked at this, I realised most of the inconsistencies were in the =E2=80=9CfetchRecords=E2=80=9D type arguments, used to reduce round trips.I= f instead we had a generic way to refer to the result of a previous method call in the arguments of a subsequent request, we can eliminate the special cases, and provide more power. Much like the unix composable-sm= all- things philosophy.Here=E2=80=99s a proposal of how this could work: Any argument name may be prefixed with a =E2=80=98#=E2=80=99. This means th= e argument value is a back-reference to the output of a previous method call rather than the real value. The value is a *ResultReference* object as described below. When processing a method call, the server MUST first check the arguments object for any names beginning with =E2=80=9C#=E2=80=9D= . If found, the back reference should be resolved and the value used as the =E2=80=9Cre= al=E2=80=9D argument. The method is then processed as normal.A *ResultReference* object= has the following properties: * *resultOf*: String The client id of the method call to get the result from (the string given as the third item in the array for a method call). * *path*: String A pointer into the arguments. This is an RFC6901 JSON Pointer, except it also allows the use of * to map through an array (see description below).To resolve: 1. Find the first response with a client id identical to the *resultOf* property of the *ResultReference* in the array of outputs from previously processed method calls in the same request. If none, evaluation fails. 2. If the response name is =E2=80=9Cerror=E2=80=9D, evaluation fails. 3. Apply the *path* to the arguments object of the response (the second item in the response array) following the RFC6901 JSON pointer algorithm, except with the following addition in Section 4 (Evaluation): If the currently referenced value is a JSON array, the reference token may be exactly the single character *, making the new referenced value the result of applying the rest of the JSON pointer tokens to every item in the array and returning the results in the same order in a new array. If the result of applying the rest of the pointer tokens to a value was itself an array, the items should be included individually in the output array rather than including the array itself (i.e. the result is flattened). 4. If the type of the result is X, and the expected type of the argument is an array of type X, wrap the result in an array with a single item.As a simple example, suppose we have the following API requ= est: [[ "getMessageUpdates", { "sinceState": "abcdef" }, "t0" ], [ "getMessages", { "#ids": { "resultOf": "t0", "path": "/changed" } }, "t1" ]]Now after executing the first method call the response array is: [[ "messageUpdates", { "accountId": "1", "oldState": "abcdef", "newState": "123456", "hasMoreUpdates": false, "changed": [ "msg1", "msg4" ], "removed": [] }, "t0" ]]So to execute the getMessages call, we lo= ok through the arguments and find there is one with a # prefix. To resolve this, we apply the algorithm above: 1. Find the first response with client id =E2=80=9Ct0=E2=80=9D. The =E2=80= =9CmessageUpdates=E2=80=9D response fulfils this criterion. 2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2=80=99s me= ssageUpdates=E2=80=9D, so this is fine. 3. Apply the *path* as a JSON pointer to the arguments object. This simply selects the =E2=80=9Cchanged=E2=80=9D property, so the result of= evaluating is: [ "msg1", "msg4" ]The JMAP server now continues to process the getM= essages call as though the arguments were: { "ids": [ "msg1", "msg4" ] }Now a more complicated example: fetch the =E2= =80=9Cfrom=E2=80=9D/=E2=80=9Ddate=E2=80=9D/=E2=80=9Dsubject=E2=80=9D for every message in the first 10 threads in the Inbox (sorted newest first): [[ "getMessageList", { "filter": { inMailbox: "id_of_inbox" }, "sort": [ "date desc" ], "collapseThreads": true, "position": 0, "limit": 10 }, "t0" ], [ "getMessages", { "#ids": { "resultOf": "t0", "path": "/ids" }, "properties": [ "threadId" ] }, "t1" ], [ "getThreads", { "#ids": { "resultOf": "t1", "path": "/list/*/threadId" } }, "t2" ], [ "getMessages", { "#ids": { "resultOf": "t2" "path": "/list/*/messageIds" }, "properties": [ "from", "date", "subject" ] }, "t3" ]]After executing t= he first 3 method calls the response array is: [[ "messageList", { "accountId": "1", "filter": { inMailbox: "id_of_inbox" }, "sort": [ "date desc" ], "collapseThreads": true, "state": "abcdefg", "canCalculateUpdates": true, "position": 0, "total": 101, "ids": [ "msg1023", "msg223", "msg110", "msg93", "msg91", "msg38", "msg36", "msg33", "msg11", "msg1" ] }, "t0" ], [ "messages", { "accountId": "1", "state": "123456", "list": [{ "id": "msg1023", "threadId": "trd194", }, { "id": "msg223", "threadId": "trd114" }, ... etc... ], "notFound": null }, "t1" ], [ "threads", { "accountId": "1", "state": "123456", "list": [{ "id: "trd194", "messageIds": [ "msg1020", "msg1021", "msg1023" ] }, { "id: "trd114", "messageIds": [ "msg201", "msg223" ] }, ... etc... ], "notFound": null }, "t2" ]]So to execute the fi= nal getMessages call, we look through the arguments and find there is one with a # prefix. To resolve this, we apply the algorithm: 1. Find the first response with client id =E2=80=9Ct2=E2=80=9D. The =E2=80= =9Cthreads=E2=80=9D response fulfils this criterion. 2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2=80=99s th= reads=E2=80=9D, so this is fine. 3. Apply the *path* as a JSON pointer to the arguments object. Token-by-token: 1. *list* =E2=80=93 get the array of thread objects 2. *** =E2=80=93 for each of the items in the array: 1. *messsageIds* =E2=80=93 get the array of message ids 2. Concatenate these into a single array of all the ids in the result.The JMAP server now continues to process the getMessages= call as though the arguments were: { "ids": [ "msg1020", "msg1021", "msg1023", "msg201", "msg223", etc... ], "properties": [ "from", "date", "subject" ] }For reference, in case i= t=E2=80=99s clearer than my description, here=E2=80=99s a JavaScript implementation of the pointer resolution algorithm, with the addition to RFC6901 clearly marked: function evaluatePointer ( value, pointer ) { if ( !pointer ) { return value; } if ( pointer.charAt( 0 ) !=3D=3D '/' ) { throw new Error( 'Invalid pointer' ); } let token; let next =3D pointer.indexOf( '/', 1 ); if ( next !=3D=3D -1 ) { token =3D pointer.slice( 1, next ); pointer =3D pointer.slic= e( next ); } else { token =3D pointer.slice( 1 ); pointer =3D ''; } token =3D token.replace( /~1/g, '/' ).replace( /~0/g, '~' ); if ( Array.isArray( value ) ) { if ( /^(?:0|[1-9][0-9]*)$/.test( token ) ) { return evaluatePointer( value[ parseInt( token, 10 ) ], pointer ); } /* start: the only bit that differs from RFC6901 */ if ( token =3D=3D=3D '*' ) { /* M= ap values to pointer */ value =3D value.map( item =3D> evaluatePointer( item, pointer ) ); /* Flatten output */ return value.reduce( ( output, item ) =3D> { if ( !Array.isArray( item ) ) { item =3D [ item ]; } return output.concat( item ); }, [] ); } /* end */ } else if ( value !=3D=3D null && typeof value =3D=3D=3D 'object' ) { return evaluatePointer( value[ token= ], pointer ); } throw new Error( 'Evaluation failed' ); }So: * What do people think of the result-reference concept to replace the fetchRecords etc. arguments and reduce the amount of special-casing? * Presuming agreement this is a good idea, is this syntax good? If not, please suggest an alternative! (I've tried to reuse RFC6901 as much as possible as the only relevant standard I'm aware of, but if you know of another standard that's more suitable please let me know). The full change proposal can be seen in the pull request at https://github.com/jmapio/jmap/pull/148. Cheers, Neil. --_----------=_15069018126760091 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi all,

This week I have been doing a lot of copy editing to remove a huge amoun= t of duplicative text, which made the spec harder to read, and more likely = to contain inconsistencies between methods. My goal is that the JMAP Mail s= pec should just be:

  1. The data type definitions
  2. Which standard method types can be used with each data type (e.g. the Th= read
    object is not mutable directly by the client so there is no setThreads= method).
  3. Any changes to the standard method for that particular type (= extra arguments
    etc.)

This makes the spec much shorter, more understandable a= nd easier to implement. Doing this also makes it easier to see where method= s for a particular type deviate from the =E2=80=9Cstandard=E2=80=9D JMAP ge= t/set calls. As I looked at this, I realised most of the inconsistencies we= re in the =E2=80=9CfetchRecords=E2=80=9D type arguments, used to reduce rou= nd trips.

If instead we had a generic way to refer to the result = of a previous method call in the arguments of a subsequent request, we can = eliminate the special cases, and provide more power. Much like the unix com= posable-small-things philosophy.

Here=E2=80=99s a proposal of how= this could work:

Any argument name may be prefixed with a =E2=80= =98#=E2=80=99. This means the argument value is a back-reference to the out= put of a previous method call rather than the real value. The value is a ResultReference object as described below. When processing a method ca= ll, the server MUST first check the arguments object for any names beginnin= g with =E2=80=9C#=E2=80=9D. If found, the back reference should be resolved= and the value used as the =E2=80=9Creal=E2=80=9D argument. The method is t= hen processed as normal.

A ResultReference object has the = following properties:

  • resultOf: String
    The client id of the method call to get the result from (the string gi= ven as the third item in the array for a method call).
  • path: String
    A pointer into the arguments. This is an RFC6901 JSON Pointer, except = it also allows the use of * to map through an array (see descr= iption below).

To resolve:

  1. Find the first response with a c= lient id identical to the resultOf property of the = ResultReference in the array of outputs from previously p= rocessed method calls in the same request. If none, evaluation fails.

  2. If the response name is =E2=80=9Cerror=E2=80=9D, eval= uation fails.

  3. Apply the path to the arguments obj= ect of the response (the second item in the response array) followi= ng the RFC6901 JSON pointer algorithm, except with the following addition i= n Section 4 (Evaluation):

    If the currently referenced va= lue is a JSON array, the reference token may be exactly the single = character *, making the new= referenced value the result of applying the rest of the JSON pointer token= s to every item in the array and returning the results in the same order in= a new array. If the result of applying the rest of the pointer tokens to a= value was itself an array, the items should be included individually in th= e output array rather than including the array itself (i.e. the result is f= lattened).

  4. If the type of the result is X, and the expected type of the ar= gument is an array of type X, wrap the result in an array with a si= ngle item.

As a simple example, suppose we have = the following API request:

[[ "getMessageUpdates", {
    "sinceState": "abcdef"
}, "t0" ],
[ "getMessages", {
    "#ids": {
        "resultOf": "t0",
        "path": "/changed"
    }
}, "t1" ]]

Now after executing the first method call the= response array is:

[[ "messageUpdates", {
    "accountId": "1",
    "oldState": "abcdef",
    "newState": "123456",
    "hasMoreUpdates": false,
    "changed": [ "msg1", "msg4" ],
    "removed": []
}, "t0" ]]

So to execute the getMessages call, we look t= hrough the arguments and find there is one with a # prefix. To= resolve this, we apply the algorithm above:

  1. Find the f= irst response with client id =E2=80=9Ct0=E2=80=9D. The =E2=80=9CmessageUpda= tes=E2=80=9D response
    fulfils this criterion.
  2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2= =80=99s messageUpdates=E2=80=9D, so this is
    fine.
  3. Apply the path as a JSON pointer to the arguments obje= ct. This simply
    selects the =E2=80=9Cchanged=E2=80=9D property, so the result of evalu= ating is:
    [ "msg1", "msg4" ]

The JMAP server now continues to process the getMessages call = as though the arguments were:

{
    "ids": [ "msg1", "msg4" ]
}

Now a more complicated example: fetch the =E2=80=9Cfrom= =E2=80=9D/=E2=80=9Ddate=E2=80=9D/=E2=80=9Dsubject=E2=80=9D for every messag= e in the first 10 threads in the Inbox (sorted newest first):

<=
code>[[ "getMessageList", {
  "filter": { inMailbox: "id_of_inbox" },
  "sort": [ "date desc" ],
  "collapseThreads": true,
  "position": 0,
  "limit": 10
}, "t0" ],
[ "getMessages", {
  "#ids": {
    "resultOf": "t0",
    "path": "/ids"
  },
  "properties": [ "threadId" ]
}, "t1" ],
[ "getThreads", {
  "#ids": {
    "resultOf": "t1",
    "path": "/list/*/threadId"
  }
}, "t2" ],
[ "getMessages", {
  "#ids": {
    "resultOf": "t2"
    "path": "/list/*/messageIds"
  },
  "properties": [ "from", "date", "subject"=
 ]
}, "t3" ]]

After executing the first 3 method calls the = response array is:

[[ "messageList", {
    "accountId": "1",
    "filter": { inMailbox: "id_of_inbox" },
    "sort": [ "date desc" ],
    "collapseThreads": true,
    "state": "abcdefg",
    "canCalculateUpdates": true,
    "position": 0,
    "total": 101,
    "ids": [ "msg1023", "msg223", "msg110", "msg93", "msg91", "msg38", "msg=
36", "msg33", "msg11", "msg1" ]
}, "t0" ],
[ "messages", {
    "accountId": "1",
    "state": "123456",
    "list": [{
        "id": "msg1023",
        "threadId": "trd194",
    }, {
        "id": "msg223",
        "threadId": "trd114"
    },=20
    ... etc...=20
    ],
    "notFound": null
}, "t1" ],
[ "threads", {
    "accountId": "1",
    "state": "123456",
    "list": [{
        "id: "trd194",
        "messageIds": [ "msg1020", "msg1021", "msg1023" ]
    }, {
        "id: "trd114",
        "messageIds": [ "msg201", "msg223" ]
    },=20
    ... etc...=20
    ],
    "notFound": null
}, "t2" ]]

So to execute the final getMessages call, we look throu= gh the arguments and find there is one with a # prefix. To res= olve this, we apply the algorithm:

  1. Find the first respo= nse with client id =E2=80=9Ct2=E2=80=9D. The =E2=80=9Cthreads=E2=80=9D resp= onse
    fulfils this criterion.
  2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2=80= =99s threads=E2=80=9D, so this is fine.
  3. Apply the path<= /i> as a JSON pointer to the arguments object. Token-by-token:
    1. list =E2=80=93 get the array of = thread objects
    2. * =E2=80=93 for each of the items in the array:
      1. messsageIds =E2=80=93 get the ar= ray of message ids
      2. Concatenate these into a single array of all the ids in the r= esult.

The JMAP server now continues to process the getMess= ages call as though the arguments were:

{
    "ids": [ "msg1020", "msg1021", "msg1023", "msg201", "msg223", etc... ],=

    "properties": [ "from", "date", "sub=
ject" ]
}

For reference, in case it=E2=80=99s clearer than my de= scription, here=E2=80=99s a JavaScript implementation of the pointer resolu= tion algorithm, with the addition to RFC6901 clearly marked:

function evaluatePointer ( value, pointer ) {
    if ( !pointer ) {
        return value;
    }
    if ( pointer.charAt( 0 ) !=3D=3D '/' ) {
        throw new Error( 'Invalid pointer' );
    }
    let token;
    let next =3D pointer.indexOf( '/', 1 );
    if ( next !=3D=3D -1 ) {
        token =3D pointer.slice( 1, next );
        pointer =3D pointer.slice( next );
    } else {
        token =3D pointer.slice( 1 );
        pointer =3D '';
    }
    token =3D token.replace( /~1/g, '/' ).replace( /~0/g, '~' );
    if ( Array.isArray( value ) ) {
        if ( /^(?:0|[1-9][0-9]*)$/.test( token ) ) {
            return evaluatePointer( value[ parseInt( token, 10 ) ], pointer=
 );
        }
        /* start: the only bit that differ=
s from RFC6901 */
        if ( token =3D=3D=3D '*' ) {
            /* Map values to pointer */
            value =3D value.map( item =3D> evaluatePointer( item, pointe=
r ) );
            /* Flatten output */
            return value.reduce( ( output, item ) =3D> {
                if ( !Array.isArray( item ) ) {
                    item =3D [ item ];
                }
                return output.concat( item );
            }, [] );
        }
        /* end */
    } else if ( value !=3D=3D null && typeof value =3D=3D=3D 'objec=
t' ) {
        return evaluatePointer( value[ token ], pointer );
    }
    throw new Error( 'Evaluation failed' );
}
So:
  • What do people think of the result-reference concept to replace the= fetchRecords etc. arguments and reduce the amount of special-casing?
  • Presuming agreement this is a good idea, is this syntax good? If not= , please suggest an alternative! (I've tried to reuse RFC6901 as much as po= ssible as the only relevant standard I'm aware of, but if you know of anoth= er standard that's more suitable please let me know).
The full change proposal can be seen in the pull request at https://github.com/jmapio/jm= ap/pull/148.

Cheers,
Neil.
--_----------=_15069018126760091-- From nobody Sun Oct 1 18:19:07 2017 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 05D02134BD4 for ; Sun, 1 Oct 2017 18:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=EfsfLNlf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qa6jdOCs 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 F-Uno9dD2bGN for ; Sun, 1 Oct 2017 18:19:03 -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 9EFFD13307D for ; Sun, 1 Oct 2017 18:19:03 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id E2E12209F8 for ; Sun, 1 Oct 2017 21:19:02 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 01 Oct 2017 21:19:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dJiMYnMnC8YRK4kPp SCvY8l6vfJUn/+rUSdibX56ZMI=; b=EfsfLNlf3D7I458w3uXBX6hzksw/SPN2w XrbIl00tRCJbBGd5DwGf/5/usKD22pQOq4fvHspw2da9n0Yq/fqq6baILvivbsbR n3I0CEDLVJI0NM3+wOVlYc1bSzC4GfvW/isIZ56W0VmJrImE6qpSNDQybNpEugW+ Hm+ZcJUxuKgzCSt0pourGigUVmNAGojMwDQGoF9MIQXJsIBWweDzabRV7s3Jgx4g JZ9mR1AS9rrZ8wdt2cDAMUTHi+5rMJcuqX4ulrSqMK8IrARyGE2Cx7o7j1/CzapT xGR/4QziEZyRmiPX5kK3J01y6doCxU+onqzYx7zDxkZ6rschVU8NA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dJiMYn MnC8YRK4kPpSCvY8l6vfJUn/+rUSdibX56ZMI=; b=qa6jdOCs5qWmgjF/tJWO+V 3wghpCcHCsgGgc2arYIVFJWlMpQje1XYMurXbMCd2Eg9KUQajBTEbFRxLwofNiKA G1axOWoiq+nVKTkCVB6b3cKt3mPpSOQXlGs8MhAx2wpIlNUwM0Cxv117B4l736Gj 8rx9NNdr4MJB/mo5ZxdK5YuDK2bPVjMlqqzQg0nmQ0ZzmyvlG0XE/MOeDgHIqJAW SlJg4jNePryucIuUEaNfEPfToIUwzjYZVDJgZAYooT5+d8s5s9KKAMVb/O1pvwpQ CeunhbHURf1uXJyRc9N71qTHDyX1bI7c1Zd65g4Pg1Ez4I6XxISUx+7UM1UtbjKQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 949E9E21CC; Sun, 1 Oct 2017 21:19:02 -0400 (EDT) Message-Id: <1506907142.744416.1124468000.58571981@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15069071427444160" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5f0bf376 In-Reply-To: <1505709437.2183546.1109331544.21752C4F@webmail.messagingengine.com> Date: Mon, 02 Oct 2017 12:19:02 +1100 References: <1505709437.2183546.1109331544.21752C4F@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Push specification X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 01:19:05 -0000 This is a multi-part message in MIME format. --_----------=_15069071427444160 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 18 Sep 2017, at 03:37 PM, Neil Jenkins wrote: > The only outstanding comment I believe I currently have from Martin is > to define when encryption may be omitted. If the push server is > controlled by the same entity as the JMAP server then there is clearly > no benefit in encrypting the payload (presuming the connection between > the client and the push server is itself encrypted anyway). I have now added a brief discussion about this to the security considerations section and merged the changes. The full changes are summarised in the commit message[1]. Cheers, Neil. Links: 1. https://github.com/jmapio/jmap/commit/337fcdfb4b45b556f4ce1b53f5235fa9e3c667ce --_----------=_15069071427444160 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 18 Sep 2017, at 03:37 PM, Neil Jenkins wrote:
The only outstanding comment I believe I currently have from Martin is to define when encryption may be omitted. If the push server is controlled by the same entity as the JMAP server then there is clearly no benefit in encrypting the payload (presuming the connection between the client and the push server is itself encrypted anyway).

I have now added a brief discussion about this to the security considerations section and merged the changes. The full changes are summarised in the commit message.

Cheers,
Neil.
--_----------=_15069071427444160-- From nobody Sun Oct 1 20:05:36 2017 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 587A2134237 for ; Sun, 1 Oct 2017 20:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=PmWsx0tn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gWJT6ZmF 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 AJQlmU12en2W for ; Sun, 1 Oct 2017 20:05:33 -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 71C7A1321CB for ; Sun, 1 Oct 2017 20:05:33 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id DDCD22256A for ; Sun, 1 Oct 2017 23:05:32 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 01 Oct 2017 23:05:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Jx4vQ4tA5yKljPbM++aM2zLB3xlqtLA5G0hKJwKG8 YA=; b=PmWsx0tnuovHFQWoI+fL/we5Lw0bsRx1lOcQnugC2FEyp7mjubbU4x1Ie KcbKBrXtAoCCoj8vVcuRZEDBUGEDc2H5reQ7BPB/GuNDv3g1KJlq8MjM02uBW1+u JZ0cShs9PdjzczWuX6UkypwSROBmbpBXPXsZbPIUnUKIytQodtzrhBhM60qwGIRm VMwB+NDpTmgTRs8OeCFuk1jiSsJvMO55bfDL5oBKqcltO/eKiHrAsp3fpzfl06cy qOiUy7xR3fDjMgSUKEaW4p5xhXpHw6IzcpBsZJlKL1YY/H49t9aEq+jmNiHl6me4 Zod37TizzywTh4y1UDUOurwRSB1fg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Jx4vQ4tA5yKljPbM++aM2zLB3xlqt LA5G0hKJwKG8YA=; b=gWJT6ZmFSQkV139vXO+6tP4Yqm7o5fnBid1xcuKIaUz41 Wtc/LsbgYvqqqxBMDhgpJRZoLsV10xcT3A1euxYaDQeoTiwLaebqeZe/3NrjzEgk bPTLeNmUxB8Pt5PRkZ3jwm59uboVnp0ICQw4I6ovJfKyf0w23Kxjk+lochglnIjd +gJqOMKqzQ5gB2JdPMACjsHSdTyRvP8+rU6S/fRKcAA+M4l6zxe0aqR8fDAcLU6d gvzF+Aa0PAr47BcgMi870y0OA1DFaT9r+lpWnvBnvFrytmwu9xuQ4m5zb9Z9Se/f 6Gk0Ovpzz8OHpg9eXqzqypBn3VYRxpCLmM3oL6r2Q== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9414AE24A6; Sun, 1 Oct 2017 23:05:32 -0400 (EDT) Message-Id: <1506913532.827302.1124530352.095C39E3@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15069135328273020" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5f0bf376 Date: Mon, 02 Oct 2017 14:05:32 +1100 Archived-At: Subject: [Jmap] Mailbox#role vs IMAP SPECIAL-USE X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 03:05:35 -0000 This is a multi-part message in MIME format. --_----------=_15069135328273020 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" This is in reference to GitHub issue #62[1]. The role attribute on the Mailbox object in JMAP is equivalent to the RFC6154[2] SPECIAL-USE flag in IMAP, however there are some semantic differences so I'd like to solicit some opinions on what to do. Here are all the differences I can see: 1. The value is singular in JMAP, but you can have multiple special-use attributes on the same mailbox in IMAP. 2. The value is unique in JMAP (you cannot have two "Sent" mailboxes), but duplicates are allowed in IMAP. 3. The value is immutable in JMAP, but can be modified after mailbox creation in IMAP. In addition, JMAP has two roles that don't exist in SPECIAL-USE: * *inbox* (It's a hard-coded name in IMAP so you didn't need an attribute). * *templates* (Drafts that should be used as the basis for new drafts but not themselves modified.) SPECIAL-USE has two attributes that aren't in JMAP: * \All * \Flagged These are both virtual, and aren't necessary in JMAP because getMessageList allows you to fetch all/flagged across the whole account without requiring a special mailbox fox it. So, what to do. Special-use allows servers to enforce the three differences in semantics that JMAP specifies (singular, unique, immutable), so one option is to leave the semantics as is, and IMAP servers can just enforce them over IMAP as well to keep a consistent view. Alternatively we can relax the restrictions in JMAP, but I think these are useful properties and I wonder whether there are people actually making use of the relaxed options at the moment with IMAP? Regarding the different roles/attributes, there's RFC6154 didn't create an IANA registry, so it's not extensible without a whole new RFC. I'm inclined to just include a mapping in an advice to implementors section. Any other opinions on this? Cheers, Neil. Links: 1. https://github.com/jmapio/jmap/issues/62 2. https://tools.ietf.org/html/rfc6154 --_----------=_15069135328273020 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
This is in reference to GitHub issue #62.

The role attribute on the Mailbox object in JMAP is equivalent to the RFC6154 SPECIAL-USE flag in IMAP, however there are some semantic differences so I'd like to solicit some opinions on what to do. Here are all the differences I can see:

  1. The value is singular in JMAP, but you can have multiple special-use attributes on the same mailbox in IMAP.
  2. The value is unique in JMAP (you cannot have two "Sent" mailboxes), but duplicates are allowed in IMAP.
  3. The value is immutable in JMAP, but can be modified after mailbox creation in IMAP.

In addition, JMAP has two roles that don't exist in SPECIAL-USE:

  • inbox (It's a hard-coded name in IMAP so you didn't need an attribute).
  • templates (Drafts that should be used as the basis for new drafts but not themselves modified.)

SPECIAL-USE has two attributes that aren't in JMAP:

  • \All
  • \Flagged

These are both virtual, and aren't necessary in JMAP because getMessageList allows you to fetch all/flagged across the whole account without requiring a special mailbox fox it.

So, what to do. Special-use allows servers to enforce the three differences in semantics that JMAP specifies (singular, unique, immutable), so one option is to leave the semantics as is, and IMAP servers can just enforce them over IMAP as well to keep a consistent view. Alternatively we can relax the restrictions in JMAP, but I think these are useful properties and I wonder whether there are people actually making use of the relaxed options at the moment with IMAP?

Regarding the different roles/attributes, there's RFC6154 didn't create an IANA registry, so it's not extensible without a whole new RFC. I'm inclined to just include a mapping in an advice to implementors section.

Any other opinions on this?

Cheers,
Neil.
--_----------=_15069135328273020-- From nobody Mon Oct 2 03:18:59 2017 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 302FB13458B for ; Mon, 2 Oct 2017 03:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=CBa6UMm+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RpljyLOF 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 O9uZOBZS6g9a for ; Mon, 2 Oct 2017 03:18:55 -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 BB966134586 for ; Mon, 2 Oct 2017 03:18:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C9958227E2 for ; Mon, 2 Oct 2017 06:18:53 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 02 Oct 2017 06:18:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4roHJumDOvcA7hr44 6rNBTyr4Z5ozddN6axyXz6/wm0=; b=CBa6UMm+iL4PGZ5ZAY5WwYPkcnZKVV5ez YJHWv+9UwtuXSrastzb1xH3br5m5+/mntmhvZ4doiOXZaYKunqMaij356IQBS/zJ On2iM8NGySxQbB2ur2AaFar2pMp00VC2nDI0XZtgq2ORyk8taeeL6fkXJDgtfRuW fRsxi6JY0IHbNbmQQlB1t1RTASQ1x0VUG+nElDFnNT8AkOmDQipa5UQfc5EP39Lu scryJJchWUkQVIjLtbb0m1lyKyEUUhi6EZA8SVoVoj8ljzqfQZC4isFk1X5GWj/m X9Kmf3gexbLV8+KTngQ5+frx77+n9vLxswBqBCRHonUInvbMLI5kg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4roHJu mDOvcA7hr446rNBTyr4Z5ozddN6axyXz6/wm0=; b=RpljyLOFDlqQz0icKF1mHE dDS+/8dvspj4rF752Wgq2wFsuqzelpqJsX2ktzz8BZZRhTwa52ilvPbM+4hhjUro U9SN2OjGQa7oLOXeQ11/PQKLvBA3MbIs7BOl4Xq9zNxwtkocneITS0aM31pewYls ThJaWh/+H20+nfhkoN5tKzDNpLzS29GLOLfO1SjR/ay0xbKVBOMw7PUG8uGuIe5A CoB4yUEbGlcFw4wOqD2oFX2vIaVQoEuIIqGiZleVIb96EAqwe2sdHF3p99KljhAm CeAo5ufN+Aa+d7sgbHYUQo/2aO0Xd2wWsyKOGvU6Yorr1EB1dXRZc9JpxNZU4qnQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A54E4BAB5B; Mon, 2 Oct 2017 06:18:53 -0400 (EDT) Message-Id: <1506939533.1938038.1124810552.6A165E33@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150693953319380383" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cb49228 References: <1506901811.676009.1124417296.5EB56E32@webmail.messagingengine.com> Date: Mon, 02 Oct 2017 06:18:53 -0400 In-Reply-To: <1506901811.676009.1124417296.5EB56E32@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Using the result of one method as a subsequent method argument X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 10:18:57 -0000 This is a multi-part message in MIME format. --_----------=_150693953319380383 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sun, 1 Oct 2017, at 19:50, Neil Jenkins wrote: > > 1. Find the first response with a client id identical to the > *resultOf* property of the *ResultReference* in the array of > outputs from previously processed method calls in the same > request. If none, evaluation fails. > 2. If the response name is =E2=80=9Cerror=E2=80=9D, evaluation fails. > 3. Apply the *path* to the arguments object of the response (the > second item in the response array) following the RFC6901 JSON > pointer algorithm, except with the following addition in Section 4 > (Evaluation): > If the currently referenced value is a JSON array, the reference token > may be exactly the single character *, making the new referenced value > the result of applying the rest of the JSON pointer tokens to every > item in the array and returning the results in the same order in a new > array. If the result of applying the rest of the pointer tokens to a > value was itself an array, the items should be included individually > in the output array rather than including the array itself (i.e. the > result is flattened). [...] > So to execute the getMessages call, we look through the arguments and > find there is one with a # prefix. To resolve this, we apply the > algorithm above: > 1. Find the first response with client id =E2=80=9Ct0=E2=80=9D. The =E2= =80=9CmessageUpdates=E2=80=9D > response fulfils this criterion. > 2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2=80=99s = messageUpdates=E2=80=9D, so > this is fine. > 3. Apply the *path* as a JSON pointer to the arguments object. This > simply selects the =E2=80=9Cchanged=E2=80=9D property, so the result = of evaluating > is: [ "msg1", "msg4" ] I guess we're not returning multiple responses, or if we are we're guaranteeing an order? A safer and clearer way might actually be to make the JSON pointer be a more full path: [[ "getMessageUpdates", { "sinceState": "abcdef" }, "t0" ], [ "getMessages", { "#ids": { "resultOf": "t0", "path": "/messageUpdates/changed" } }, "t1" ]] This removes the "ignore responses which are 'error'" special case. I guess if we wanted to make it more explicit fields: [[ "getMessageUpdates", { "sinceState": "abcdef" }, "t0" ], [ "getMessages", { "#ids": { "resultOf": "t0", "resultType" : "messageUpdates", "path": "/changed" } }, "t1" ]] Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150693953319380383 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Sun, 1 Oct 2017, at 19:50, Neil = Jenkins wrote:

  1. Find the first response with a client id identical to the res= ultOf property of the ResultReference in = the array of outputs from previously processed method calls in the same re= quest. If none, evaluation fails.

  2. If the response= name is =E2=80=9Cerror=E2=80=9D, evaluation fails.

  3. Appl= y the path to the arguments object of the response (the second item = in the response array) following the RFC6901 JSON pointer algorithm= , except with the following addition in Section 4 (Evaluation):
    <= /p>

    If the currently referenced value is a JSON array, the reference to= ken may be exactly the single character *<= /code>, making the new referenced value the result of applying the rest = of the JSON pointer tokens to every item in the array and returning the res= ults in the same order in a new array. If the result of applying the rest o= f the pointer tokens to a value was itself an array, the items should be in= cluded individually in the output array rather than including the array its= elf (i.e. the result is flattened).

[...]

So to execute t= he getMessages call, we look through the arguments and find there is one wi= th a # prefix. To resolve this, we apply the algorithm above:<= br>
  1. Find the first response with client id =E2=80=9Ct0=E2=80=9D. T= he =E2=80=9CmessageUpdates=E2=80=9D response
    fulfils this criterion.
  2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2= =80=99s messageUpdates=E2=80=9D, so this is
    fine.
  3. Apply the path as a JSON pointer to the arguments obje= ct. This simply
    selects the =E2=80=9Cchanged=E2=80=9D property, so the result of evalu= ating is:
    [ "msg1", "msg4" ]

I guess we're not returning multiple resp= onses, or if we are we're guaranteeing an order?

A safer and clearer way might actually be= to make the JSON pointer be a more full path:


[[ "getMessageUpdates", {
    "sinceState": "abcdef"
}, "t0" ],
[ "getMessages", {
    "#ids": {
        "resultOf": "t0",
        "path": "/messageUpdates/changed"
    }
}, "t1" ]]

This removes the "ignore res=
ponses which are 'error'" special case.  I guess if we wanted to make it mo=
re explicit fields:


[[ "g=
etMessageUpdates", {
    "sinceState": "abcdef"
}, "t0" ],
[ "getMessages", {
    "#ids": {
        "resultOf": "t0",
        "resultType" :=
 "messageUpdates",
        "path": "/changed"
    }
}, "t1" ]]




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


--_----------=_150693953319380383-- From nobody Mon Oct 2 06:46:39 2017 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 B6CFF13447F for ; Mon, 2 Oct 2017 06:46:38 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHDz4iJPQJWz for ; Mon, 2 Oct 2017 06:46:31 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCB5134460 for ; Mon, 2 Oct 2017 06:46:28 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id c67so4578355qkg.2 for ; Mon, 02 Oct 2017 06:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=uK/EtPUhF/U/LWZ3Hxvd0tNQryUFydQxjBqkdSUKNCQ=; b=fM5uxcw2SJiftlMPfvWD+wiD8rbCPM4dm7W/5b+fanyBQjuLfDvOc7kzw5Ct78O9Rz vSZNRLrvSq9CCxF85W2nFeNP8RGGBCqad3IUUYXkoWD/GTAmsHFXOzDPj9a7vNJsdabF c7EV5fshjOFQva2i+UpTD7C3uf+UWn3sjaoVfsap7giHCVJs4JQZZgiZ1exRHv8MhEEr oO5Rchp3xzFpwBcTSQe60+8i77CO/F2kYZhCclLLrDTnNPAYp0sz44PLrnRqvAO6pw+x 7kXxXWJvk4GIK49o/7EAKttyeYLF1oFcq2TTqZLTFT7gSND2FBkW97U09+m2ZnVU/+Td gMkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=uK/EtPUhF/U/LWZ3Hxvd0tNQryUFydQxjBqkdSUKNCQ=; b=jG8iLwE04oReV22cmJ63cEBjN7eHe/X8euQoP2owBdiKwGnIHgE4cKK0zDee+WeBCV NBXQktaw7S6r+oC93dCORwiqBxhE//ogRL0/xdfGB6eiQHPoN6mGutT0bpQy2nYmViFu 4oeotBSvFWC2VcbCKhsTuyA9lRi+S/4QGTIebQPq4BB8etfcXPxeHBulMjA706C5ontI ztZDPb13WN5PgkWAaQB5JY5h76mATfuNNsE8yMI4Dpab+QxX+gXOreXS0W//PVS3K+i+ 7UUzAyY33jp8KQU/XFahgZ4SnGScSkZEtSjZMmnpvYNrDFlIUhHYElrSuQR1tcAEnTqt jyOw== X-Gm-Message-State: AMCzsaWhHTQruuvlCIj5UAazChf8uVNPB9VxQyIbZpRQV2a7aQnqwFTx CeBGmSiYHCPUL1MKpnBJqGpz1m5j98kn65YCxQS+oA== X-Google-Smtp-Source: AOwi7QAkKXZvuaofvvQ+6u7pnIjfYEbdLZdOIVlC8woi3H48q7STtpoLTiR8Ing3vnm6Whdaf8YBBsUAmJuibAvlynU= X-Received: by 10.55.47.70 with SMTP id v67mr15384136qkh.324.1506951987980; Mon, 02 Oct 2017 06:46:27 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 2 Oct 2017 06:46:27 -0700 From: Gren Elliot In-Reply-To: <1506913532.827302.1124530352.095C39E3@webmail.messagingengine.com> References: <1506913532.827302.1124530352.095C39E3@webmail.messagingengine.com> X-Mailer: Airmail (452) MIME-Version: 1.0 Date: Mon, 2 Oct 2017 06:46:27 -0700 Message-ID: To: Neil Jenkins , IETF JMAP Mailing List Content-Type: multipart/alternative; boundary="001a114f2ac4eff0f4055a909969" Archived-At: Subject: Re: [Jmap] Mailbox#role vs IMAP SPECIAL-USE X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 13:46:39 -0000 --001a114f2ac4eff0f4055a909969 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m inclined to think there is value in JMAP being more restrictive= . If IMAP exposes multiple =E2=80=9CSent=E2=80=9D mailboxes for instance, the JM= AP implementation could provide an aggregated view of them in a similar way to how the =E2=80=9Call mail=E2=80=9D view would be done. Similarly, if =E2= =80=9CSent=E2=80=9D and =E2=80=9CDrafts=E2=80=9D are on the same IMAP mailbox - JMAP could present 2 views onto the underlying implementation of this. There are of course issues (where do Sent messages end up?) but I don=E2=80=99t think allowing multiple Sent mai= lboxes addresses that issue anyway. Having said this, I=E2=80=99m not aware of any actual instances where this = is a problem - I have seen multiple Sent mailboxes created by different (IMAP and non-IMAP) clients but I don=E2=80=99t think I=E2=80=99ve seen more than= one of them flagged for special use. Regards, Gren Elliot From: Neil Jenkins Reply: Neil Jenkins Date: 2 October 2017 at 04:05:38 To: IETF JMAP Mailing List Subject: [Jmap] Mailbox#role vs IMAP SPECIAL-USE This is in reference to GitHub issue #62 . The role attribute on the Mailbox object in JMAP is equivalent to the RFC6154 SPECIAL-USE flag in IMAP, however there are some semantic differences so I'd like to solicit some opinions on what to do. Here are all the differences I can see: 1. The value is singular in JMAP, but you can have multiple special-use attributes on the same mailbox in IMAP. 2. The value is unique in JMAP (you cannot have two "Sent" mailboxes), but duplicates are allowed in IMAP. 3. The value is immutable in JMAP, but can be modified after mailbox creation in IMAP. In addition, JMAP has two roles that don't exist in SPECIAL-USE: - *inbox* (It's a hard-coded name in IMAP so you didn't need an attribute). - *templates* (Drafts that should be used as the basis for new drafts but not themselves modified.) SPECIAL-USE has two attributes that aren't in JMAP: - \All - \Flagged These are both virtual, and aren't necessary in JMAP because getMessageList allows you to fetch all/flagged across the whole account without requiring a special mailbox fox it. So, what to do. Special-use allows servers to enforce the three differences in semantics that JMAP specifies (singular, unique, immutable), so one option is to leave the semantics as is, and IMAP servers can just enforce them over IMAP as well to keep a consistent view. Alternatively we can relax the restrictions in JMAP, but I think these are useful properties and I wonder whether there are people actually making use of the relaxed options at the moment with IMAP? Regarding the different roles/attributes, there's RFC6154 didn't create an IANA registry, so it's not extensible without a whole new RFC. I'm inclined to just include a mapping in an advice to implementors section. Any other opinions on this? Cheers, Neil. _______________________________________________ Jmap mailing list Jmap@ietf.org https://www.ietf.org/mailman/listinfo/jmap --001a114f2ac4eff0f4055a909969 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I=E2=80=99m inclined to think there is value in J= MAP being more restrictive.=C2=A0 If IMAP exposes multiple =E2=80=9CSent=E2= =80=9D mailboxes for instance, the JMAP implementation could provide an agg= regated view of them in a similar way to how the =E2=80=9Call mail=E2=80=9D= view would be done.=C2=A0 Similarly, if =E2=80=9CSent=E2=80=9D and =E2=80= =9CDrafts=E2=80=9D are on the same IMAP mailbox - JMAP could present 2 view= s onto the underlying implementation of this.=C2=A0 There are of course iss= ues (where do Sent messages end up?) but I don=E2=80=99t think allowing mul= tiple Sent mailboxes addresses that issue anyway.

Having said this, I=E2=80=99m not aware of any= actual instances where this is a problem - I have seen multiple Sent mailb= oxes created by different (IMAP and non-IMAP) clients but I don=E2=80=99t t= hink I=E2=80=99ve seen more than one of them flagged for special use.
=
Regards,
Gren Elliot

From:=C2=A0Neil Jenkins <neilj@fastmailteam.com>
Reply:=C2=A0Neil Jenkins = <neilj@fastmailteam.com>
Date:=C2=A02 October 2017 at 04:05:38
To:=C2=A0IETF JMAP Mailing List <jmap@ie= tf.org>
Subject:=C2=A0 [Jmap] Mailbox= #role vs IMAP SPECIAL-USE

This is in reference to GitHub issue #62.

The role attribute on the Mailbox object in JMAP is equivalent to the RFC6154 SPECIAL-USE flag in IMAP, however there are some semantic differences so I'd like to solicit some opinions on what to do. Here are all the differences I can see:

  1. The value is singular in JMAP, but you can have multiple special-use attributes on the same mailbox in IMAP.
  2. The value is unique in JMAP (you cannot have two "Sent" mailboxes), but duplicates are allowed in IMAP.
  3. The value is immutable in JMAP, but can be modified after mailbox creation in IMAP.

In addition, JMAP has two roles that don't exist in SPECIAL-USE:

  • inbox (It's a hard-coded name in IMAP so you didn't need an attribute).
  • templates (Drafts that should be used as the basis for new drafts but not themselves modified.)

SPECIAL-USE has two attributes that aren't in JMAP:

  • \All
  • \Flagged

These are both virtual, and aren't necessary in JMAP because getMessageList allows you to fetch all/flagged across the whole account without requiring a special mailbox fox it.

So, what to do. Special-use allows servers to enforce the three differences in semantics that JMAP specifies (singular, unique, immutable), so one option is to leave the semantics as is, and IMAP servers can just enforce them over IMAP as well to keep a consistent view. Alternatively we can relax the restrictions in JMAP, but I think these are useful properties and I wonder whether there are people actually making use of the relaxed options at the moment with IMAP?

Regarding the different roles/attributes, there's RFC6154 didn't create an IANA registry, so it's not extensible without a whole new RFC. I'm inclined to just include a mapping in an advice to implementors section.

Any other opinions on this?

Cheers,
Neil.
_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf= .org/mailman/listinfo/jmap
--001a114f2ac4eff0f4055a909969-- From nobody Mon Oct 2 07:00:04 2017 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 766B413447F for ; Mon, 2 Oct 2017 07:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=brasslantern-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 3huChhUvnlUA for ; Mon, 2 Oct 2017 07:00:00 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 D95F813464A for ; Mon, 2 Oct 2017 06:59:59 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id e19so3455959qta.13 for ; Mon, 02 Oct 2017 06:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7luvzOubApq/lnJVO/lh4iX502KkieLAd/5rsIc+nOc=; b=CPdjChOyszfUAfRs+ZzVAuYxVWPE5neH2sXJjhXCn3w11pqArpAHbp7N723YeDw5Oc e4Hd8vJibyqa+FWZ4AhKoLT1LdnKwLeKCPZanCBJNnlgnaZZzZmI6SfMYkql+Ih4+deq tJSviS1ON9pDx08kdxB6kLcw1YUKv39qNAeaxBTAyH2mDuPUkhqWInYDFgE4EADkazSn PRL1S0cIraYgdsnLdI2DNXdtbjV3zFciix+6QGTICj3wmVLeW+W/Zo4YKSGrb5jeHYEi r+QeYz9V2qNl2pC0TW0E2at7Btol7H5u+vHZHIdFoI0mVKGhyO3vTxWI1YycwbVjrVUk PfXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7luvzOubApq/lnJVO/lh4iX502KkieLAd/5rsIc+nOc=; b=VsoH9LOzQoIiHVRXCrkPD71AQX6744tvtX37Pm6peOZfFA9XMHV7cNdL7QxC5K/bqR UNaSAvz+ikEfChia4A30OSaga3edwNkgFtzLFUlpe6E+5LFHdCTZQ6Rm6zi0/X9Y0ojB pya6OXeC5PqHhzO0KYBDdmPVPwUFY67rtO3zSQPxpygjBOizKpPG9K94gQ9fpQTb/ckr MCMvqXH3qkFLVLbvA8usEhEAvuGSeAGGBGdo788ra6zEzhW7ksA8ug4HOqymnUC7Po1V BLMrTnf1Fbph1FUnIBUF09DZ/LZfCMVKuzr4UpkA4Ngo98crjZGytlHOOg1uzRmn8wzO tlJQ== X-Gm-Message-State: AMCzsaVj37dOhZdnapedI23jWOXyM/b+8mprugnAfJEC0aysKy8R9mlw NsNwpTfIlXzhAMbSyOYMuaK4RrA6kKQIlsjG1pmCnA== X-Google-Smtp-Source: AOwi7QBdH//CSpLubaKnd15MIdD/XVAAaAY1yMrF9ZD2c0fcPARh4Ejv/uWy4FfhmcijITVx6MUpVQLLlgS0BXXpU40= X-Received: by 10.200.15.8 with SMTP id e8mr19978315qtk.315.1506952798690; Mon, 02 Oct 2017 06:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.84 with HTTP; Mon, 2 Oct 2017 06:59:58 -0700 (PDT) In-Reply-To: <1506901811.676009.1124417296.5EB56E32@webmail.messagingengine.com> References: <1506901811.676009.1124417296.5EB56E32@webmail.messagingengine.com> From: Bart Schaefer Date: Mon, 2 Oct 2017 06:59:58 -0700 Message-ID: To: IETF JMAP Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jmap] Using the result of one method as a subsequent method argument X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 14:00:01 -0000 On Sun, Oct 1, 2017 at 4:50 PM, Neil Jenkins wrote: > > If instead we had a generic way to refer to the result of a previous method Doesn't that violate HTTP statelessness? Bron's subsequent suggestion is much more RESTy. From nobody Mon Oct 2 07:15:54 2017 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 6A9E4134304 for ; Mon, 2 Oct 2017 07:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=mK1vUi98; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z4yKvioA 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 wxStKw0LfXC8 for ; Mon, 2 Oct 2017 07:15:51 -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 A07D81345D4 for ; Mon, 2 Oct 2017 07:15:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E1DFE2277C for ; Mon, 2 Oct 2017 10:15:50 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 02 Oct 2017 10:15:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kr7a8Ar2TIkgObbsF VOAzCD0988jej1yhpKAD2AwigA=; b=mK1vUi98VKhYXHKaS5FUIHWdMkS2TnlQ6 8G4SLEyhFnA/qacNcJhcGtRYBjB15D1PtUkgxeWq5IdQw4ielz945sA7bkkDeKwA GBR4PHIpGuyAIeO9iZpcSEak8u2bnoc0va2MzQ/DgPCtRilNctViJ/BHWlWqc8XK KOjsN7B9krssGpw9ykxw6acztcn9XYz0gv3kQgrc/5+2QGCRETc+qmpqm7kXlARS apqBm9u/6++KOnBts9N90W/Hy8OXCyMakNrybbgZN384TC7J6i0NW5lUsFMT2ZFD nwgwf5Lu4xDUiHagVWKlv3bYhDYdsHaG0NvOEub5FO2UdQCcxn0Wg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kr7a8A r2TIkgObbsFVOAzCD0988jej1yhpKAD2AwigA=; b=Z4yKvioAVJb4Sem3NSdq7d bcE6aE82Fup0k6NIWxm1Qjwx5NkJxZcf3jFLkNenoM/VLw9qzEd1iBo5Nd7XpRVr buBkP4kWJ3sVolLwB34SO0qhQUnh7v5Fft+AXYjQPHcG6oFjXJC0TKpxCttPqgHg /Rm+B6EZF4QyfWxQYJdSoMwUigNBsFiY7WqQzJJKvS31cqoENTKk6JcPr3XpORJI qqjJklEa5559CtDFIh3ZZeokXEFVZF/PejaWvHN3nqAlXd3fQeeKBTyeGTjnDZXJ 7wuwnnNVWWpqQtk9WApMCQrpiGcGSjerOrnssiPONZUYuu+a1fuahHX72Ky8iJdA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B849E9E304; Mon, 2 Oct 2017 10:15:50 -0400 (EDT) Message-Id: <1506953750.111547.1125055112.0C8A0171@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15069537501115473" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cb49228 In-Reply-To: Date: Mon, 02 Oct 2017 10:15:50 -0400 References: <1506901811.676009.1124417296.5EB56E32@webmail.messagingengine.com> Archived-At: Subject: Re: [Jmap] Using the result of one method as a subsequent method argument X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 14:15:53 -0000 This is a multi-part message in MIME format. --_----------=_15069537501115473 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 2 Oct 2017, at 09:59, Bart Schaefer wrote: > On Sun, Oct 1, 2017 at 4:50 PM, Neil Jenkins > wrote: >> >> If instead we had a generic way to refer to the result of a >> previous method> > Doesn't that violate HTTP statelessness? > > Bron's subsequent suggestion is much more RESTy. JMAP methods are multiple method calls batched together, so a single HTTP request can refer to results created by the previous method within the same request. The state already needs to be kept for ids of created resources from previous methods to allow ID backreferences, so this is just extending it to keep data (which will also be ID lists, realistically) from previous get methods as well. As a server implementer, there's very little difference in what I'd be doing to support this - the fetchRecords in the current draft is also implemented as a called to the next getFoos with the ids parameter pre- filled from a previous dataset. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15069537501115473 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 2 Oct 2017, at 09:59, Bart Schaefer wrote:
On Sun, Oct 1, 2017 at 4:50 PM, Neil Jenkins <neilj@fastmailteam.com>
wrote:

If instead we had a generic way to refer to the result of a previous method

Doesn't that violate HTTP statelessness?

Bron's subsequent suggestion is much more RESTy.

JMAP methods are multiple method calls batched together, so a single HTTP request can refer to results created by the previous method within the same request.

The state already needs to be kept for ids of created resources from previous methods to allow ID backreferences, so this is just extending it to keep data (which will also be ID lists, realistically) from previous get methods as well.

As a server implementer, there's very little difference in what I'd be doing to support this - the fetchRecords in the current draft is also implemented as a called to the next getFoos with the ids parameter pre-filled from a previous dataset.

Bron.


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


--_----------=_15069537501115473-- From nobody Mon Oct 2 11:25:36 2017 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 85872134707 for ; Mon, 2 Oct 2017 11:25:34 -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, URIBL_BLOCKED=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 AJzpIFOyYiiL for ; Mon, 2 Oct 2017 11:25:32 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4F04813471A for ; Mon, 2 Oct 2017 11:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1506968701; d=isode.com; s=june2016; i=@isode.com; bh=D/jsQmURwuySZ0FnK/av1fyt/d1bE1o8ZLMGlcdknAM=; 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=BPPXj+a8VAGfzbv7vxezkBLVgw3Ry7cKCZiB5yEJfC4dypoxZ60QFRyC0OxTinrwWOTooh IKKKy0LQFXxQ4lNUjNwBdysoSV1MkJcXMQOmjlcBhjc7j5hEiDWsSFxvHnrerR1g/iQIpm hmHH7xrKkRXSluQWYxtu9uNetR22gAc=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 2 Oct 2017 19:25:01 +0100 From: Alexey Melnikov To: Neil Jenkins , IETF JMAP Mailing List References: <1506913532.827302.1124530352.095C39E3@webmail.messagingengine.com> Message-ID: <52a1d603-f004-99e4-f181-56b004018a14@isode.com> Date: Mon, 2 Oct 2017 19:24:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <1506913532.827302.1124530352.095C39E3@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------221894165D3D6FE842626939" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Mailbox#role vs IMAP SPECIAL-USE X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 18:25:34 -0000 This is a multi-part message in MIME format. --------------221894165D3D6FE842626939 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Neil, On 02/10/2017 04:05, Neil Jenkins wrote: > This is in reference to GitHub issue #62 > . > > The role attribute on the Mailbox object in JMAP is equivalent to the > RFC6154 SPECIAL-USE flag in > IMAP, however there are some semantic differences so I'd like to > solicit some opinions on what to do. Here are all the differences I > can see: > > 1. The value is singular in JMAP, but you can have multiple > special-use attributes on the same mailbox in IMAP. > 2. The value is unique in JMAP (you cannot have two "Sent" > mailboxes), but duplicates are allowed in IMAP. > 3. The value is immutable in JMAP, but can be modified after mailbox > creation in IMAP. > Just to double check: by immutable you mean that a special use attribute is set upon mailbox creation and can't be changed after that? > In addition, JMAP has two roles that don't exist in SPECIAL-USE: > > * /inbox/ (It's a hard-coded name in IMAP so you didn't need an > attribute). > * /templates/ (Drafts that should be used as the basis for new > drafts but not themselves modified.) > > > SPECIAL-USE has two attributes that aren't in JMAP: > > * \All > * \Flagged > > > These are both virtual, and aren't necessary in JMAP because > getMessageList allows you to fetch all/flagged across the whole > account without requiring a special mailbox fox it. Agreed, that the last 2 are not needed in JMAP. > So, what to do. Special-use allows servers to enforce the three > differences in semantics that JMAP specifies (singular, unique, > immutable), so one option is to leave the semantics as is, and IMAP > servers can just enforce them over IMAP as well to keep a consistent > view. Alternatively we can relax the restrictions in JMAP, but I think > these are useful properties and I wonder whether there are people > actually making use of the relaxed options at the moment with IMAP? I think keeping JMAP restrictions is Ok. From my experience writing an IMAP client that uses SPECIAL-USE, uniqueness is useful (otherwise I have to pick one of the values in the IMAP client). I don't find lack of singularity to be an issue, but I can live with it as a restriction. Immutability is also Ok, although I am Ok with adding special use to an existing mailbox. (Isode's IMAP server would allow for that). > Regarding the different roles/attributes, there's RFC6154 didn't > create an IANA registry, so it's not extensible without a whole new > RFC. I'm inclined to just include a mapping in an advice to > implementors section. I think we should create a registry. But this can be done in the EXTRA WG, if you don't want to do that in your draft. > Any other opinions on this? > Best Regards, Alexey --------------221894165D3D6FE842626939 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Neil,


On 02/10/2017 04:05, Neil Jenkins wrote:
This is in reference to GitHub issue #62.

The role attribute on the Mailbox object in JMAP is equivalent to the RFC6154 SPECIAL-USE flag in IMAP, however there are some semantic differences so I'd like to solicit some opinions on what to do. Here are all the differences I can see:

  1. The value is singular in JMAP, but you can have multiple special-use attributes on the same mailbox in IMAP.
  2. The value is unique in JMAP (you cannot have two "Sent" mailboxes), but duplicates are allowed in IMAP.
  3. The value is immutable in JMAP, but can be modified after mailbox creation in IMAP.
Just to double check: by immutable you mean that a special use attribute is set upon mailbox creation and can't be changed after that?

In addition, JMAP has two roles that don't exist in SPECIAL-USE:

  • inbox (It's a hard-coded name in IMAP so you didn't need an attribute).
  • templates (Drafts that should be used as the basis for new drafts but not themselves modified.)

SPECIAL-USE has two attributes that aren't in JMAP:

  • \All
  • \Flagged

These are both virtual, and aren't necessary in JMAP because getMessageList allows you to fetch all/flagged across the whole account without requiring a special mailbox fox it.
Agreed, that the last 2 are not needed in JMAP.

So, what to do. Special-use allows servers to enforce the three differences in semantics that JMAP specifies (singular, unique, immutable), so one option is to leave the semantics as is, and IMAP servers can just enforce them over IMAP as well to keep a consistent view. Alternatively we can relax the restrictions in JMAP, but I think these are useful properties and I wonder whether there are people actually making use of the relaxed options at the moment with IMAP?
I think keeping JMAP restrictions is Ok. From my experience writing an IMAP client that uses SPECIAL-USE, uniqueness is useful (otherwise I have to pick one of the values in the IMAP client). I don't find lack of singularity to be an issue, but I can live with it as a restriction. Immutability is also Ok, although I am Ok with adding special use to an existing mailbox. (Isode's IMAP server would allow for that).

Regarding the different roles/attributes, there's RFC6154 didn't create an IANA registry, so it's not extensible without a whole new RFC. I'm inclined to just include a mapping in an advice to implementors section.
I think we should create a registry. But this can be done in the EXTRA WG, if you don't want to do that in your draft.

Any other opinions on this?

Best Regards,
Alexey

--------------221894165D3D6FE842626939-- From nobody Mon Oct 2 11:36:14 2017 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 C0199134724 for ; Mon, 2 Oct 2017 11:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=fMtPSKh0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cBbaVDi3 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 2mel3m186K7u for ; Mon, 2 Oct 2017 11:36:09 -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 6133B134749 for ; Mon, 2 Oct 2017 11:34:32 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A0170229A5 for ; Mon, 2 Oct 2017 14:34:31 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 02 Oct 2017 14:34:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=5mGD3sFmLuUjEkivb 8xK9mKfv50hIMKerQhSx12zYb4=; b=fMtPSKh0v6lwP7/MzdX0VuFakulWJCnEi 1reUc6Y6lKKTsRecnBgjg32gy/RKREwKlZBGymyu+EH07fe1+hdVkVlYyHsCMuRo trR97PRy/ULp1AMEY+WLgkrh+Q8eaU+0QxZt3rO0TfAw0eCLJ84VtxPQopLGabZF oqnBPvg/ZgHqMtYK05bQLPqec5I5kOGrNAxjDDKaDThym/wsBqt/jxFrelRpdmeW qBW7ufIUXZix2RYJptaLer/1N6GzksLqaahGpjIw+1zX2a+DbJI0G98CF8cSYp4u 0y5wH8H8dUOSedsDj3J3sPQ/uk4fxXYo2akpF53/zLf6NcQ95zZtQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=5mGD3s FmLuUjEkivb8xK9mKfv50hIMKerQhSx12zYb4=; b=cBbaVDi3PvFI+DwLqZggTq M5srfWar5Ea1RPhmldqi4qkCZywgRxoAZ5VNMsEnesuXkz2bkk7Y0lvP7DYcY9JD z9D4bZGpJsgZZnO6Uziq+vc3dbr5afcHgaQGhtd91oO6Mj75hsW8SOBj8ZC/KnFj 07IFEwmqe1SqWzwlvdL6Ea/KUBj55x6AcOAj+PjIstFqd8lKDO6sbmMENE0HyX06 wmxajJHvf1C9izbnL1JVgnBPW2u0NNFji4w+j5qw1l5CCL/OjOS3mtbNwaxLLujY mJO79rxZO0n0tvuo/WsYNGp6Tdo8UDSvDRjBn5f0rke59urcxKktUoAGHdkErckw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7F0D395799; Mon, 2 Oct 2017 14:34:31 -0400 (EDT) Message-Id: <1506969271.2787352.1125373784.1C3CF907@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150696927127873520" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cb49228 In-Reply-To: <52a1d603-f004-99e4-f181-56b004018a14@isode.com> References: <1506913532.827302.1124530352.095C39E3@webmail.messagingengine.com> <52a1d603-f004-99e4-f181-56b004018a14@isode.com> Date: Mon, 02 Oct 2017 14:34:31 -0400 Archived-At: Subject: Re: [Jmap] Mailbox#role vs IMAP SPECIAL-USE X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 18:36:13 -0000 This is a multi-part message in MIME format. --_----------=_150696927127873520 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 2 Oct 2017, at 14:24, Alexey Melnikov wrote: > Just to double check: by immutable you mean that a special use > attribute is set upon mailbox creation and can't be changed > after that? > So, what to do. Special-use allows servers to enforce the three > differences in semantics that JMAP specifies (singular, unique, > immutable), so one option is to leave the semantics as is, and IMAP > servers can just enforce them over IMAP as well to keep a > consistent view. Alternatively we can relax the restrictions in > JMAP, but I think these are useful properties and I wonder whether > there are people actually making use of the relaxed options at the > moment with IMAP? I changed the Cyrus server to only allow a single mailbox with each Special- use value. Further more, you can only create them or set those special-use annotations on mailboxes which are at the top level - this is because people kept dragging their Archive folder into their Trash or similar nonsense. Apparently some clients make this far too easy to do. Then other clients would notice that the folder was missing and re-create it (complete with the use) because select-by-use is not a thing. Oh yeah - finally, you can't delete a folder with a special-use (though you can remove the use and THEN delete it) > I think keeping JMAP restrictions is Ok. From my experience writing an > IMAP client that uses SPECIAL-USE, uniqueness is useful (otherwise I > have to pick one of the values in the IMAP client). I don't find lack > of singularity to be an issue, but I can live with it as a > restriction. Immutability is also Ok, although I am Ok with adding > special use to an existing mailbox. (Isode's IMAP server would allow > for that). Cyrus allows adding the special-use later as well, subject to the above mentioned restrictions. >> Regarding the different roles/attributes, there's RFC6154 didn't >> create an IANA registry, so it's not extensible without a whole new >> RFC. I'm inclined to just include a mapping in an advice to >> implementors section.> I think we should create a registry. But this can be done in the EXTRA > WG, if you don't want to do that in your draft. I agree that EXTRA is the right place for this. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150696927127873520 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 2 Oct 2017, at 14:24, Alexey Melnikov wrote:

Just to double check: by immutable you mean that a special use attribute is set upon mailbox creation and can't be changed after that?



So, what to do. Special-use allows servers to enforce the three differences in semantics that JMAP specifies (singular, unique, immutable), so one option is to leave the semantics as is, and IMAP servers can just enforce them over IMAP as well to keep a consistent view. Alternatively we can relax the restrictions in JMAP, but I think these are useful properties and I wonder whether there are people actually making use of the relaxed options at the moment with IMAP?

I changed the Cyrus server to only allow a single mailbox with each Special-use value.

Further more, you can only create them or set those special-use annotations on mailboxes which are at the top level - this is because people kept dragging their Archive folder into their Trash or similar nonsense.  Apparently some clients make this far too easy to do.  Then other clients would notice that the folder was missing and re-create it (complete with the use) because select-by-use is not a thing.

Oh yeah - finally, you can't delete a folder with a special-use (though you can remove the use and THEN delete it)

I think keeping JMAP restrictions is Ok. From my experience writing an IMAP client that uses SPECIAL-USE, uniqueness is useful (otherwise I have to pick one of the values in the IMAP client). I don't find lack of singularity to be an issue, but I can live with it as a restriction. Immutability is also Ok, although I am Ok with adding special use to an existing mailbox. (Isode's IMAP server would allow for that).

Cyrus allows adding the special-use later as well, subject to the above mentioned restrictions.

Regarding the different roles/attributes, there's RFC6154 didn't create an IANA registry, so it's not extensible without a whole new RFC. I'm inclined to just include a mapping in an advice to implementors section.
I think we should create a registry. But this can be done in the EXTRA WG, if you don't want to do that in your draft.

I agree that EXTRA is the right place for this.

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


--_----------=_150696927127873520-- From nobody Mon Oct 2 17:54:12 2017 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 48B161342EE for ; Mon, 2 Oct 2017 17:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13k-FeCoVvp6 for ; Mon, 2 Oct 2017 17:54:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD0A1201F8 for ; Mon, 2 Oct 2017 17:54:07 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v930s3tg029937 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Oct 2017 00:54:04 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v930s3IB015196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Oct 2017 00:54:03 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v930s2uA031438; Tue, 3 Oct 2017 00:54:02 GMT Received: from [10.145.239.184] (/10.145.239.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Oct 2017 17:54:02 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: "IETF JMAP Mailing List" Date: Mon, 02 Oct 2017 17:54:00 -0700 Message-ID: In-Reply-To: <1506901811.676009.1124417296.5EB56E32@webmail.messagingengine.com> References: <1506901811.676009.1124417296.5EB56E32@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_71703970-9151-4D82-9D5E-3D0DE88B167C_=" Embedded-HTML: [{"HTML":[1834, 12392], "plain":[493, 8939], "uuid":"4E439EDF-865B-4977-BE0A-DAD7129B8743"}] X-Mailer: MailMate (1.9.7r5419) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Jmap] Using the result of one method as a subsequent method argument X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 00:54:10 -0000 --=_MailMate_71703970-9151-4D82-9D5E-3D0DE88B167C_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable RFC 5182 is useful to save round-trips. I support the concept in JMAP. = I'd be careful about over-generalizing the back-reference model as that = seems like the type of over-generalization that can make server = implementations unnecessarily complex without significant added benefit. = Also, RFC 5182 includes a mechanism that avoids sending data to the = client that the client doesn't need, which may be worth thinking about = in this case. - Chris On 1 Oct 2017, at 16:50, Neil Jenkins wrote: > Hi all, > This week I have been doing a lot of copy editing to remove a huge > amount of duplicative text, which made the spec harder to read, and = > more > likely to contain inconsistencies between methods. My goal is that the > JMAP Mail spec should just be: > > > 1. The data type definitions > 2. Which standard method types can be used with each data type (e.g. > the Thread object is not mutable directly by the client so there = > is > no setThreads method). > 3. Any changes to the standard method for that particular type (extra > arguments etc.)This makes the spec *much* shorter, more = > understandable and easier to > implement. Doing this also makes it easier to see where methods for a > particular type deviate from the =E2=80=9Cstandard=E2=80=9D JMAP get/se= t calls. As = > I > looked at this, I realised most of the inconsistencies were in the > =E2=80=9CfetchRecords=E2=80=9D type arguments, used to reduce round tri= ps.If = > instead we had a generic way to refer to the result of a previous > method call in the arguments of a subsequent request, we can eliminate > the special cases, and provide more power. Much like the unix = > composable-small- > things philosophy.Here=E2=80=99s a proposal of how this could work: > > > Any argument name may be prefixed with a =E2=80=98#=E2=80=99. This mean= s the = > argument > value is a back-reference to the output of a previous method call = > rather > than the real value. The value is a *ResultReference* object as > described below. When processing a method call, the server MUST first > check the arguments object for any names beginning with =E2=80=9C#=E2=80= =9D. If = > found, > the back reference should be resolved and the value used as the = > =E2=80=9Creal=E2=80=9D > argument. The method is then processed as normal.A *ResultReference* = > object has the following properties: > > > * *resultOf*: String The client id of the method call to get the > result from (the string given as the third item in the array for a > method call). > * *path*: String A pointer into the arguments. This is an RFC6901 = > JSON > Pointer, except it also allows the use of * to map through an array > (see description below).To resolve: > > > 1. Find the first response with a client id identical to the = > *resultOf* > property of the *ResultReference* in the array of outputs from > previously processed method calls in the same request. If none, > evaluation fails. > > > 2. If the response name is =E2=80=9Cerror=E2=80=9D, evaluation fails. > > > 3. Apply the *path* to the arguments object of the response (the = > second > item in the response array) following the RFC6901 JSON pointer > algorithm, except with the following addition in Section 4 > (Evaluation): > > > If the currently referenced value is a JSON array, the reference token > may be exactly the single character *, making the new referenced value > the result of applying the rest of the JSON pointer tokens to every = > item > in the array and returning the results in the same order in a new = > array. > If the result of applying the rest of the pointer tokens to a value = > was > itself an array, the items should be included individually in the = > output > array rather than including the array itself (i.e. the result is > flattened). > 4. If the type of the result is X, and the expected type of the > argument is an array of type X, wrap the result in an array with a > single item.As a simple example, suppose we have the following API = > request: > > > [[ "getMessageUpdates", { "sinceState": "abcdef" }, "t0" ], [ > "getMessages", { "#ids": { "resultOf": "t0", "path": "/changed" } > }, "t1" ]]Now after executing the first method call the response array = > is: > > > [[ "messageUpdates", { "accountId": "1", "oldState": "abcdef", > "newState": "123456", "hasMoreUpdates": false, "changed": [ "msg1", > "msg4" ], "removed": [] }, "t0" ]]So to execute the getMessages call, = > we look through the arguments and > find there is one with a # prefix. To resolve this, we apply the > algorithm above: > > > 1. Find the first response with client id =E2=80=9Ct0=E2=80=9D. The = > =E2=80=9CmessageUpdates=E2=80=9D > response fulfils this criterion. > 2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2=80=99= s = > messageUpdates=E2=80=9D, so > this is fine. > 3. Apply the *path* as a JSON pointer to the arguments object. This > simply selects the =E2=80=9Cchanged=E2=80=9D property, so the resul= t of = > evaluating > is: [ "msg1", "msg4" ]The JMAP server now continues to process the = > getMessages call as though > the arguments were: > > > { "ids": [ "msg1", "msg4" ] }Now a more complicated example: fetch the = > =E2=80=9Cfrom=E2=80=9D/=E2=80=9Ddate=E2=80=9D/=E2=80=9Dsubject=E2=80=9D= > for every message in the first 10 threads in the Inbox (sorted > newest first): > > > [[ "getMessageList", { "filter": { inMailbox: "id_of_inbox" }, "sort": = > [ > "date desc" ], "collapseThreads": true, "position": 0, "limit": 10 }, > "t0" ], [ "getMessages", { "#ids": { "resultOf": "t0", "path": "/ids" = > }, > "properties": [ "threadId" ] }, "t1" ], [ "getThreads", { "#ids": { > "resultOf": "t1", "path": "/list/*/threadId" } }, "t2" ], [ > "getMessages", { "#ids": { "resultOf": "t2" "path": = > "/list/*/messageIds" > }, "properties": [ "from", "date", "subject" ] }, "t3" ]]After = > executing the first 3 method calls the response array is: > > > [[ "messageList", { "accountId": "1", "filter": { inMailbox: > "id_of_inbox" }, "sort": [ "date desc" ], "collapseThreads": true, > "state": "abcdefg", "canCalculateUpdates": true, "position": 0, = > "total": > 101, "ids": [ "msg1023", "msg223", "msg110", "msg93", "msg91", = > "msg38", > "msg36", "msg33", "msg11", "msg1" ] }, "t0" ], [ "messages", { > "accountId": "1", "state": "123456", "list": [{ "id": "msg1023", > "threadId": "trd194", }, { "id": "msg223", "threadId": "trd114" }, ... > etc... ], "notFound": null }, "t1" ], [ "threads", { "accountId": "1", > "state": "123456", "list": [{ "id: "trd194", "messageIds": [ = > "msg1020", > "msg1021", "msg1023" ] }, { "id: "trd114", "messageIds": [ "msg201", > "msg223" ] }, ... etc... ], "notFound": null }, "t2" ]]So to execute = > the final getMessages call, we look through the arguments > and find there is one with a # prefix. To resolve this, we apply the > algorithm: > > > 1. Find the first response with client id =E2=80=9Ct2=E2=80=9D. The =E2= =80=9Cthreads=E2=80=9D = > response > fulfils this criterion. > 2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2=80=99= s threads=E2=80=9D, so > this is fine. > 3. Apply the *path* as a JSON pointer to the arguments object. > Token-by-token: > 1. *list* =E2=80=93 get the array of thread objects > 2. *** =E2=80=93 for each of the items in the array: > 1. *messsageIds* =E2=80=93 get the array of message ids > 2. Concatenate these into a single array of all the ids in > the result.The JMAP server now continues to process the = > getMessages call as though > the arguments were: > > > { "ids": [ "msg1020", "msg1021", "msg1023", "msg201", "msg223", etc... > ], "properties": [ "from", "date", "subject" ] }For reference, in = > case it=E2=80=99s clearer than my description, here=E2=80=99s a > JavaScript implementation of the pointer resolution algorithm, with = > the > addition to RFC6901 clearly marked: > > > function evaluatePointer ( value, pointer ) { if ( !pointer ) { return > value; } if ( pointer.charAt( 0 ) !=3D=3D '/' ) { throw new Error( = > 'Invalid > pointer' ); } let token; let next =3D pointer.indexOf( '/', 1 ); if ( = > next > !=3D=3D -1 ) { token =3D pointer.slice( 1, next ); pointer =3D pointer.= slice( > next ); } else { token =3D pointer.slice( 1 ); pointer =3D ''; } token = =3D > token.replace( /~1/g, '/' ).replace( /~0/g, '~' ); if ( Array.isArray( > value ) ) { if ( /^(?:0|[1-9][0-9]*)$/.test( token ) ) { return > evaluatePointer( value[ parseInt( token, 10 ) ], pointer ); } /* = > start: > the only bit that differs from RFC6901 */ if ( token =3D=3D=3D '*' ) { = /* = > Map > values to pointer */ value =3D value.map( item =3D> evaluatePointer( it= em, > pointer ) ); /* Flatten output */ return value.reduce( ( output, item = > ) > =3D> { if ( !Array.isArray( item ) ) { item =3D [ item ]; } return > output.concat( item ); }, [] ); } /* end */ } else if ( value !=3D=3D n= ull > && typeof value =3D=3D=3D 'object' ) { return evaluatePointer( value[ t= oken = > ], > pointer ); } throw new Error( 'Evaluation failed' ); }So: > * What do people think of the result-reference concept to replace the > fetchRecords etc. arguments and reduce the amount of = > special-casing? > * Presuming agreement this is a good idea, is this syntax good? If = > not, > please suggest an alternative! (I've tried to reuse RFC6901 as much > as possible as the only relevant standard I'm aware of, but if you > know of another standard that's more suitable please let me know). > The full change proposal can be seen in the pull request at > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_jmapi= o_jmap_pull_148&d=3DDwIFaQ&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK1= 0&r=3DQBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3DCtS0Ut-8SOYtTU2EShd= 7Qt1Wa66iG5eF637_nimF-OM&s=3D8kEj1hBS8M2M_XaHaB3x831iSoNkmvDpY8cNsW5gYiA&= e=3D = > . > Cheers, > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_jmap&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DQBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3DCtS0Ut-8SOYtTU2E= Shd7Qt1Wa66iG5eF637_nimF-OM&s=3Dh4UnZPECDHeyTajis8WzolSW6T9P-tPU7kMtP8abZ= cM&e=3D --=_MailMate_71703970-9151-4D82-9D5E-3D0DE88B167C_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

RFC 5182 is useful to save round= -trips. I support the concept in JMAP. I'd be careful about over-gene= ralizing the back-reference model as that seems like the type of over-gen= eralization that can make server implementations unnecessarily complex wi= thout significant added benefit. Also, RFC 5182 includes a mechanism that= avoids sending data to the client that the client doesn't need, whic= h may be worth thinking about in this case.

- Chris

On 1 Oct 2017, at 16:50, Neil Jenkins wrote:

Hi all,

This week I have been doing a lot of copy editing to remove a huge amo= unt of duplicative text, which made the spec harder to read, and more lik= ely to contain inconsistencies between methods. My goal is that the JMAP = Mail spec should just be:

  1. The data type definitions
  2. Which standard method types can be used with each data type (e= =2Eg. the Thread
    object is not mutable directly by the client so there is no setThrea= ds method).
  3. Any changes to the standard method for that particular type= (extra arguments
    etc.)

This makes the spec much shorter, more understandable= and easier to implement. Doing this also makes it easier to see where me= thods for a particular type deviate from the =E2=80=9Cstandard=E2=80=9D J= MAP get/set calls. As I looked at this, I realised most of the inconsiste= ncies were in the =E2=80=9CfetchRecords=E2=80=9D type arguments, used to = reduce round trips.

If instead we had a generic way to refer to= the result of a previous method call in the arguments of a subsequent re= quest, we can eliminate the special cases, and provide more power. Much l= ike the unix composable-small-things philosophy.

Here=E2=80=99s= a proposal of how this could work:

Any argument name may be pr= efixed with a =E2=80=98#=E2=80=99. This means the argument value is a bac= k-reference to the output of a previous method call rather than the real = value. The value is a ResultReference object as described below. W= hen processing a method call, the server MUST first check the arguments o= bject for any names beginning with =E2=80=9C#=E2=80=9D. If found, the bac= k reference should be resolved and the value used as the =E2=80=9Creal=E2= =80=9D argument. The method is then processed as normal.

A R= esultReference object has the following properties:

  • resultOf: String
The client id of the method call to get the result from (the string = given as the third item in the array for a method call).
  • path: String
    A pointer into the arguments. This is an RFC6901 JSON Pointer, excep= t it also allows the use of * to map through an array (see d= escription below).

    • To resolve:

    1. Find the first response with a= client id identical to the resultOf property of the= ResultReference in the array of out= puts from previously processed method calls in the same request. If none= , evaluation fails.

    2. If the response name is =E2= =80=9Cerror=E2=80=9D, evaluation fails.

    3. Apply the p= ath to the arguments object of the response (the second item in = the response array) following the RFC6901 JSON pointer algorithm= , except with the following addition in Section 4 (Evaluation):

      If the currently referenced value is a JSON array, the referenc= e token may be exactly the single character *, making the new referenced v= alue the result of applying the rest of the JSON pointer tokens to every = item in the array and returning the results in the same order in a new ar= ray. If the result of applying the rest of the pointer tokens to a value = was itself an array, the items should be included individually in the out= put array rather than including the array itself (i.e. the result is flat= tened).

    4. If the type of the result is X, and the expected type of the = argument is an array of type X, wrap the result in an array= with a single item.

    As a simple example, supp= ose we have the following API request:

    [[ "getMessageUp=
dates", {
    "sinceState": "abcdef"
}, "t0" ],
[ "getMessages", {
    "#ids": {
        "resultOf": "t0",
        "path": "/changed"
    }
}, "t1" ]]

    Now after executing the first method call t= he response array is:

    [[ "messageUpdates", {
    "accountId": "1",
    "oldState": "abcdef",
    "newState": "123456",
    "hasMoreUpdates": false,
    "changed": [ "msg1", "msg4" ],
    "removed": []
}, "t0" ]]

    So to execute the getMessages call, we look= through the arguments and find there is one with a # prefix= =2E To resolve this, we apply the algorithm above:

    1. Fi= nd the first response with client id =E2=80=9Ct0=E2=80=9D. The =E2=80=9Cm= essageUpdates=E2=80=9D response
      fulfils this criterion.
    2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2= =80=99s messageUpdates=E2=80=9D, so this is
      fine.
    3. Apply the path as a JSON pointer to the arguments ob= ject. This simply
      selects the =E2=80=9Cchanged=E2=80=9D property, so the result of eva= luating is:
      [ "msg1", "msg4" ]

    The JMAP server now continues to process the getMessages cal= l as though the arguments were:

    {
    "ids": [ "msg1", "msg4" ]
}

    Now a more complicated example: fetch the =E2=80=9Cfr= om=E2=80=9D/=E2=80=9Ddate=E2=80=9D/=E2=80=9Dsubject=E2=80=9D for every me= ssage in the first 10 threads in the Inbox (sorted newest first):

    = 
    [[ "getMessageList", {
  "filter": { inMailbox: "id_of_inbox" },
  "sort": [ "date desc" ],
  "collapseThreads": true,
  "position": 0,
  "limit": 10
}, "t0" ],
[ "getMessages", {
  "#ids": {
    "resultOf": "t0",
    "path": "/ids"
  },
  "properties": [ "threadId" ]
}, "t1" ],
[ "getThreads", {
  "#ids": {
    "resultOf": "t1",
    "path": "/list/*/threadId"
  }
}, "t2" ],
[ "getMessages", {
  "#ids": {
    "resultOf": "t2"
    "path": "/list/*/messageIds"
  },
      "properties": [ "from", "date", "subjec=
t" ]
}, "t3" ]]

    After executing the first 3 method calls th= e response array is:

    [[ "messageList", {
    "accountId": "1",
    "filter": { inMailbox: "id_of_inbox" },
    "sort": [ "date desc" ],
    "collapseThreads": true,
    "state": "abcdefg",
    "canCalculateUpdates": true,
    "position": 0,
    "total": 101,
    "ids": [ "msg1023", "msg223", "msg110", "msg93", "msg91", "msg38", "m=
sg36", "msg33", "msg11", "msg1" ]
}, "t0" ],
[ "messages", {
    "accountId": "1",
    "state": "123456",
    "list": [{
        "id": "msg1023",
        "threadId": "trd194",
    }, {
        "id": "msg223",
        "threadId": "trd114"
    }, =

    ... etc... =

    ],
    "notFound": null
}, "t1" ],
[ "threads", {
    "accountId": "1",
    "state": "123456",
    "list": [{
        "id: "trd194",
        "messageIds": [ "msg1020", "msg1021", "msg1023" ]
    }, {
        "id: "trd114",
        "messageIds": [ "msg201", "msg223" ]
    }, =

    ... etc... =

    ],
    "notFound": null
}, "t2" ]]

    So to execute the final getMessages call, we look thr= ough the arguments and find there is one with a # prefix. To= resolve this, we apply the algorithm:

    1. Find the first= response with client id =E2=80=9Ct2=E2=80=9D. The =E2=80=9Cthreads=E2=80= =9D response
      fulfils this criterion.
    2. Check the response name is not =E2=80=9Cerror=E2=80=9D. It=E2=80= =99s threads=E2=80=9D, so this is fine.
    3. Apply the pat= h as a JSON pointer to the arguments object. Token-by-token:
      1. list =E2=80=93 get the array o= f thread objects
      2. * =E2=80=93 for each of the items in the array:=
        1. messsageIds =E2=80=93 get the = array of message ids
        2. Concatenate these into a single array of all the ids in the= result.

    The JMAP server now continues to process the getMe= ssages call as though the arguments were:

    {
    "ids": [ "msg1020", "msg1021", "msg1023", "msg201", "msg223", etc... =
],
        "properties": [ "from", "date", =
"subject" ]
}

    For reference, in case it=E2=80=99s clearer than my = description, here=E2=80=99s a JavaScript implementation of the pointer re= solution algorithm, with the addition to RFC6901 clearly marked:

    <= pre>function evaluatePointer ( value, pointer ) { if ( !pointer ) { return value; } if ( pointer.charAt( 0 ) !=3D=3D '/' ) { throw new Error( 'Invalid pointer' ); } let token; let next =3D pointer.indexOf( '/', 1 ); if ( next !=3D=3D -1 ) { token =3D pointer.slice( 1, next ); pointer =3D pointer.slice( next ); } else { token =3D pointer.slice( 1 ); pointer =3D ''; } token =3D token.replace( /~1/g, '/' ).replace( /~0/g, '~' ); if ( Array.isArray( value ) ) { if ( /^(?:0|[1-9][0-9]*)$/.test( token ) ) { return evaluatePointer( value[ parseInt( token, 10 ) ], point= er ); } /* start: the only bit that di= ffers from RFC6901 */ if ( token =3D=3D=3D '*' ) { /* Map values to pointer */ value =3D value.map( item =3D> evaluatePointer( item, poin= ter ) ); /* Flatten output */ return value.reduce( ( output, item ) =3D> { if ( !Array.isArray( item ) ) { item =3D [ item ]; } return output.concat( item ); }, [] ); } /* end */ } else if ( value !=3D=3D null && typeof value =3D=3D=3D 'obj= ect' ) { return evaluatePointer( value[ token ], pointer ); } throw new Error( 'Evaluation failed' ); }
    So: