Fwd: Request to form a new WG: JMAP
Alexey Melnikov <[email protected]> Mon, 7 Nov 2016 17:31:31 +0000
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============2441907638533348592== Content-Type: multipart/alternative; boundary="------------AF36E52C5A48EC0A6A290E83" This is a multi-part message in MIME format. --------------AF36E52C5A48EC0A6A290E83 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, I am forwarding my email here, as I suspect people on these two mailing lists might be interested in this. Please post your comments/questions to [email protected] or directly to me. Best Regards, Alexey -------- Forwarded Message -------- Subject: Request to form a new WG: JMAP Date: Mon, 07 Nov 2016 17:17:59 +0000 From: Alexey Melnikov <[email protected]> To: DISPATCH <[email protected]> Hi, I have received a request to form a new WG: JSON Mail Access Protocol (JMAP). Draft charter is included below. Please send your comments in reply to this email or directly to me. I am also looking for possible chairs for this work, so if you are interested, please contact me off-list. Thank you, Alexey ------------------------------------ Name: JSON Mail Access Protocol Acronym: jmap Area: Applications and Real-Time Area (art) Charter for Working Group Many companies and projects are developing their own JSON based representations of email which are proprietary, non-standard, and incompatible with each other. These protocols are proliferating due to existing standards being insufficient or poorly suited to the environments they are operating in, particularly mobile and webmail. The JMAP working group will specify an mechanism to allow clients to both view and send email from a server over a single stateless HTTPS channel with minimal round trips. The protocol will support out-of-band signaling of changes, and will give mobile clients significant benefits in terms of battery life and network usage. The use of multiple protocols to perform actions within a single application creates significant support challenges, as users may get a variety of partial failure modes (for example, can receive email, but can not send new messages). This is further exacerbated if the different protocols are authenticated separately. The work of this group is limited to developing a protocol for a client synchronising data with a server. Any server-to-server issues or end-to-end encryption of messages are out of scope for this working group. The working group will coordinate with the Security Area on credential management and authentication. Input to working group discussions shall include: - Internet Message Format [RFC 5322] - CONDSTORE and QRESYNC [RFC 7162] - Collection Synchronisation for WebDav [RFC 6578] - LEMONADE and experiences from adoption of its output [https://datatracker.ietf.org/wg/lemonade/charter/] - SMTP SUBMISSION [RFC 4409] - SMTP BURL [RFC 4468] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on a new protocol for client to server email synchronisation. The working group may choose not to publish this as an RFC. - A document describing an extensible protocol and data structures which supports stateless use, flood control and batched operations. - A document describing how to use the extensible protocol over HTTPS with the data structures expressed as JSON. - A document describing a data model for email viewing, management, searching, and submission on top of the extensible protocol. - An executable test suite and documented test cases to assist developers of JMAP servers to ensure they conform to the specifications. --------------AF36E52C5A48EC0A6A290E83 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=windows-1252"> </head> <body bgcolor="#FFFFFF" text="#000000"> <p>Hi,<br> </p> <p>I am forwarding my email here, as I suspect people on these two mailing lists might be interested in this.</p> <p>Please post your comments/questions to <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> or directly to me.</p> <p>Best Regards,</p> <p>Alexey<br> </p> <div class="moz-forward-container">-------- Forwarded Message -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th> <td>Request to form a new WG: JMAP</td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th> <td>Mon, 07 Nov 2016 17:17:59 +0000</td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th> <td>Alexey Melnikov <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a></td> </tr> <tr> <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th> <td>DISPATCH <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a></td> </tr> </tbody> </table> <br> <br> <pre>Hi, I have received a request to form a new WG: JSON Mail Access Protocol (JMAP). Draft charter is included below. Please send your comments in reply to this email or directly to me. I am also looking for possible chairs for this work, so if you are interested, please contact me off-list. Thank you, Alexey ------------------------------------ Name: JSON Mail Access Protocol Acronym: jmap Area: Applications and Real-Time Area (art) Charter for Working Group Many companies and projects are developing their own JSON based representations of email which are proprietary, non-standard, and incompatible with each other. These protocols are proliferating due to existing standards being insufficient or poorly suited to the environments they are operating in, particularly mobile and webmail. The JMAP working group will specify an mechanism to allow clients to both view and send email from a server over a single stateless HTTPS channel with minimal round trips. The protocol will support out-of-band signaling of changes, and will give mobile clients significant benefits in terms of battery life and network usage. The use of multiple protocols to perform actions within a single application creates significant support challenges, as users may get a variety of partial failure modes (for example, can receive email, but can not send new messages). This is further exacerbated if the different protocols are authenticated separately. The work of this group is limited to developing a protocol for a client synchronising data with a server. Any server-to-server issues or end-to-end encryption of messages are out of scope for this working group. The working group will coordinate with the Security Area on credential management and authentication. Input to working group discussions shall include: - Internet Message Format [RFC 5322] - CONDSTORE and QRESYNC [RFC 7162] - Collection Synchronisation for WebDav [RFC 6578] - LEMONADE and experiences from adoption of its output [<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/wg/lemonade/charter/">https://datatracker.ietf.org/wg/lemonade/charter/</a>] - SMTP SUBMISSION [RFC 4409] - SMTP BURL [RFC 4468] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on a new protocol for client to server email synchronisation. The working group may choose not to publish this as an RFC. - A document describing an extensible protocol and data structures which supports stateless use, flood control and batched operations. - A document describing how to use the extensible protocol over HTTPS with the data structures expressed as JSON. - A document describing a data model for email viewing, management, searching, and submission on top of the extensible protocol. - An executable test suite and documented test cases to assist developers of JMAP servers to ensure they conform to the specifications. </pre> </div> </body> </html> --------------AF36E52C5A48EC0A6A290E83-- --===============2441907638533348592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext --===============2441907638533348592==--