From nobody Thu May  1 11:36:33 2014
Return-Path: <narendrasingh.bisht@gmail.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDEE1A6FE2 for <imapext@ietfa.amsl.com>; Thu,  1 May 2014 11:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 A3o63kc3ZJ7g for <imapext@ietfa.amsl.com>; Thu,  1 May 2014 11:36:29 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 33A5C1A6FDB for <imapext@ietf.org>; Thu,  1 May 2014 11:36:29 -0700 (PDT)
Received: by mail-yk0-f175.google.com with SMTP id q200so2967856ykb.6 for <imapext@ietf.org>; Thu, 01 May 2014 11:36:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=Uh2HtA6VaXilKvVaCml9qDjLzYM8SM2Jdk3DEoHNYp8=; b=k2/zUFbFsDXMyq8IfrKcBkX+VUzYxLcyExaDOpjO0qI1jCzvNrkj7M7oD44i6b4YAs yYCUFBW3zJUa5G3Xg6pLbRqBmdNKj8HAYOZ6GMjE4/Y0bCgaoZ6gC64Cvua55KIAmZYi 9IYKF3kTG+Ys4GtIKl4qDN0FPsfzQqnPRUOBPVOPwC5R2QJ11pRZ1SGRYjbmQ9PNjeNd o550IMzhrQw3GUuGVPy+2EsLR/72uUap1/EgthpwzDHNqq2Yv5BNcW+KRtz+fjNgZHgV eQbVWQrUx8W2R+25NW4mwKuwxMPfD0VuI9Mo/WoRVYW8ZvZMgtYIm/QpUYdC+aE5pOaV Uy1Q==
X-Received: by 10.236.181.4 with SMTP id k4mr16753098yhm.129.1398969386987; Thu, 01 May 2014 11:36:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.170.157.138 with HTTP; Thu, 1 May 2014 11:36:06 -0700 (PDT)
From: narendra singh bisht <narendrasingh.bisht@gmail.com>
Date: Thu, 1 May 2014 14:36:06 -0400
Message-ID: <CAHC+rVFAMn1+U9BpLU=YsM_m=VrU3RD=YJJptMr+yftn4vWc_g@mail.gmail.com>
To: imapext@ietf.org
Content-Type: multipart/alternative; boundary=20cf3056422b5cf6d604f85af1c4
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/qioetrKrgH8XrtqJAXIeGnNKNas
Subject: [imapext] Finding out REAL Drafts folder on an IMAP Server.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2014 18:36:32 -0000

--20cf3056422b5cf6d604f85af1c4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey there,



I don=E2=80=99t know how trivial this question is, but I=E2=80=99ve been th=
inking on this a
lot.

How do I find the REAL Drafts folder on an IMAP server?

For Gmail and AOL, I could see there is some mapping in the response which
will help me find out the server=E2=80=99s draft folder.

But for lot of others server, including Yahoo.com, it seems there is no
proper and consistent way to find the server=E2=80=99s Drafts folder.

Few flavors of Drafts folder name:

Draft

Drafts

INBOX.Drafts



Please suggest a way to find it out.

--=20
Thanks & Regards
-Narendra

--20cf3056422b5cf6d604f85af1c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p class=3D"MsoNormal">Hey there,</p>

<p class=3D"MsoNormal">=C2=A0</p>

<p class=3D"MsoNormal">I don=E2=80=99t know how trivial this question is, b=
ut I=E2=80=99ve been thinking
on this a lot.</p>

<p class=3D"MsoNormal">How do I find the REAL Drafts folder on an IMAP serv=
er?</p>

<p class=3D"MsoNormal">For Gmail and AOL, I could see there is some mapping=
 in the
response which will help me find out the server=E2=80=99s draft folder.</p>

<p class=3D"MsoNormal">But for lot of others server, including Yahoo.com, i=
t seems
there is no proper and consistent way to find the server=E2=80=99s Drafts f=
older.</p>

<p class=3D"MsoNormal">Few flavors of Drafts folder name:</p>

<p class=3D"MsoNormal">Draft</p>

<p class=3D"MsoNormal">Drafts</p>

<p class=3D"MsoNormal">INBOX.Drafts</p>

<p class=3D"MsoNormal">=C2=A0</p>

<p class=3D"MsoNormal">Please suggest a way to find it out.</p><div><br></d=
iv>-- <br>Thanks &amp; Regards<div>-Narendra</div>
</div>

--20cf3056422b5cf6d604f85af1c4--


From nobody Thu May  1 14:31:35 2014
Return-Path: <brong@fastmail.fm>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B5E1A0776 for <imapext@ietfa.amsl.com>; Thu,  1 May 2014 14:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 yxA8-ltuXu_B for <imapext@ietfa.amsl.com>; Thu,  1 May 2014 14:31:32 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA5D1A06DB for <imapext@ietf.org>; Thu,  1 May 2014 14:31:32 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6FAE221464 for <imapext@ietf.org>; Thu,  1 May 2014 17:31:28 -0400 (EDT)
Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Thu, 01 May 2014 17:31:29 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= 4dEZCuCf3ARl31DmymF4R1D5+tc=; b=Dw1f0uLepI03xprjaDemtkeokm3cHi+P hauHKHdlHkEvTH3kOyO0CWRXK+5SZGczTTKNSjl0dEgXjfTuhqBP545HDmqeODIL EpYmVIOtJxYrwkjvnoX2ObDhcfHwyMPVda6QY0AUSKgoKHHSM/fDq6oq7v8Gi8B1 1/OyoMNt4Us=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=4dEZCuCf3ARl31DmymF4R1D5+tc=; b=LRa7O dABJ3aAtu0LyRP2I1cKo+iPX6H2bRP0YuOCckL6VZOrQ6Tivp8MTWPLbnqEho5nM oh78+wVBsQ2NQSXJrRt5N/EG+KeyJIa6MEhdk+fQ+XGVUwwfTaFKXqx/PFREHqem MAV97XAA4Sf4QncNzP+o6+N8MIlE+ERkCmLfNE=
Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id BDABB10D0D1; Thu,  1 May 2014 17:31:28 -0400 (EDT)
Message-Id: <1398979888.28734.112716705.6883081E@webmail.messagingengine.com>
X-Sasl-Enc: TgoAMDNMaggJN8jNjQvzfxLDFIehCsP+ImGFSPJVhluZ 1398979888
From: Bron Gondwana <brong@fastmail.fm>
To: imapext@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_1398979888287340";  charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-aafac2c3
Date: Fri, 02 May 2014 07:31:28 +1000
In-Reply-To: <CAHC+rVFAMn1+U9BpLU=YsM_m=VrU3RD=YJJptMr+yftn4vWc_g@mail.gmail.com>
References: <CAHC+rVFAMn1+U9BpLU=YsM_m=VrU3RD=YJJptMr+yftn4vWc_g@mail.gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/xJR6HxGBkfJf3uUF9gHDjLc7S5g
Subject: Re: [imapext] Finding out REAL Drafts folder on an IMAP Server.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2014 21:31:34 -0000

This is a multi-part message in MIME format.

--_----------=_1398979888287340
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Fri, May 2, 2014, at 04:36 AM, narendra singh bisht wrote:

Hey there,


I don=E2=80=99t know how trivial this question is, but I=E2=80=99ve been th=
inking on
this a lot.

How do I find the REAL Drafts folder on an IMAP server?

For Gmail and AOL, I could see there is some mapping in the response
which will help me find out the server=E2=80=99s draft folder.

This is called SPECIAL-USE, and it's documented in RFC 6154.


But for lot of others server, including Yahoo.com, it seems there is no
proper and consistent way to find the server=E2=80=99s Drafts folder.

Few flavors of Drafts folder name:

Draft

Drafts

INBOX.Drafts


Please suggest a way to find it out.

Call up the administrator of the server and ask them.

While you're at it, suggest that they implement RFC 6154.

Alternatively, it looks like running a LIST command and matching on the
word 'draft' will probably let you make a pretty good guess.

Regards,

Bron.

--
Bron Gondwana
brong@fastmail.fm

--_----------=_1398979888287340
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Fri, May 2, 2014, at 04:36 AM, narendra singh bisht wrote:<br=
></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><p>Hey there,<br></p><p>&nbsp;<b=
r></p><p>I don=E2=80=99t know how trivial this question is, but I=E2=80=99v=
e been thinking
on this a lot.<br></p><p>How do I find the REAL Drafts folder on an IMAP se=
rver?<br></p><p>For Gmail and AOL, I could see there is some mapping in the
response which will help me find out the server=E2=80=99s draft folder.<br>=
</p></div>
</blockquote><div dir=3D"ltr"><p>This is called SPECIAL-USE, and it's docum=
ented in RFC 6154.<br></p></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div defang_dir=3D"" class=3D"">=
&nbsp;</div>
<div defang_dir=3D"" class=3D"">But for lot of others server, including Yah=
oo.com, it seems
there is no proper and consistent way to find the server=E2=80=99s Drafts f=
older.<br></div>
<p>Few flavors of Drafts folder name:<br></p><p>Draft<br></p><p>Drafts<br><=
/p><p>INBOX.Drafts<br></p><p>&nbsp;<br></p><p>Please suggest a way to find =
it out.<br></p></div>
</blockquote><div dir=3D"ltr"><div>Call up the administrator of the server =
and ask them.<br></div>
<div>&nbsp;</div>
<div>While you're at it, suggest that they implement RFC 6154.<br></div>
<div>&nbsp;</div>
<div>Alternatively, it looks like running a LIST command and matching on th=
e word 'draft' will probably let you make a pretty good guess.<br></div>
<div>&nbsp;</div>
<div>Regards,<br></div>
<div>&nbsp;</div>
<div>Bron.<br></div>
<div>&nbsp;</div>
</div>
<div id=3D"sig567075"><div class=3D"signature">-- <br></div>
<div class=3D"signature">  Bron Gondwana<br></div>
<div class=3D"signature">  brong@fastmail.fm<br></div>
<div class=3D"signature">&nbsp;</div>
</div>
</body>
</html>

--_----------=_1398979888287340--


From nobody Sun May  4 08:15:50 2014
Return-Path: <paul@pscs.co.uk>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7691A08B3 for <imapext@ietfa.amsl.com>; Thu,  1 May 2014 11:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level: 
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 YrYmyBtbdktE for <imapext@ietfa.amsl.com>; Thu,  1 May 2014 11:46:51 -0700 (PDT)
Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id 69B561A091A for <imapext@ietf.org>; Thu,  1 May 2014 11:46:50 -0700 (PDT)
Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul
Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP for <imapext@ietf.org>; Thu, 1 May 2014 19:48:24 +0100
Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul
Received: from [192.168.57.132] ([217.155.61.158]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP for <imapext@ietf.org>; Thu, 1 May 2014 19:46:40 +0100
Message-ID: <53629677.7040800@pscs.co.uk>
Date: Thu, 01 May 2014 19:46:15 +0100
From: Paul Smith <paul@pscs.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: imapext@ietf.org
References: <CAHC+rVFAMn1+U9BpLU=YsM_m=VrU3RD=YJJptMr+yftn4vWc_g@mail.gmail.com>
In-Reply-To: <CAHC+rVFAMn1+U9BpLU=YsM_m=VrU3RD=YJJptMr+yftn4vWc_g@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V6.8 - Registered
X-Organisation: Paul Smith Computer Services
X-Authenticated-Sender: paul
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/hLTzsWj6pyq-_N9GXUbyJwuQl0U
X-Mailman-Approved-At: Sun, 04 May 2014 08:15:32 -0700
Subject: Re: [imapext] Finding out REAL Drafts folder on an IMAP Server.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2014 18:46:54 -0000

On 01/05/2014 19:36, narendra singh bisht wrote:
>
> Hey there,
>
> I don’t know how trivial this question is, but I’ve been thinking on 
> this a lot.
>
> How do I find the REAL Drafts folder on an IMAP server?
>
> For Gmail and AOL, I could see there is some mapping in the response 
> which will help me find out the server’s draft folder.
>
> But for lot of others server, including Yahoo.com, it seems there is 
> no proper and consistent way to find the server’s Drafts folder.
>
There is RFC 6154 (http://tools.ietf.org/html/rfc6154) but that's an 
optional extension.

Other than that, you have to guess. However, the 'Drafts' folder is just 
like any other folder (as are 'Sent Items', 'Trash', 'Junk' etc), so the 
drafts folder can be whichever folder the MUA wants it to be.



-


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53


From nobody Mon May  5 01:12:44 2014
Return-Path: <jkt@flaska.net>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AB61A0280 for <imapext@ietfa.amsl.com>; Mon,  5 May 2014 01:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.449
X-Spam-Level: 
X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 qQiRwNedMrFj for <imapext@ietfa.amsl.com>; Mon,  5 May 2014 01:12:37 -0700 (PDT)
Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 6886D1A0279 for <imapext@ietf.org>; Mon,  5 May 2014 01:12:37 -0700 (PDT)
Received: by latimerie.flaska.net (Postfix, from userid 1000) id E0A5F61B81; Mon,  5 May 2014 10:12:29 +0200 (CEST)
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
To: <imapext@ietf.org>
Date: Mon, 05 May 2014 10:12:26 +0200
User-Agent: Trojita/v0.4.1-191-gaeca318; Qt/4.8.5; X11; Linux; 
MIME-Version: 1.0
Message-ID: <954d4cb5-91a5-4c5d-9876-b77b310f4a9c@flaska.net>
In-Reply-To: <1398979888.28734.112716705.6883081E@webmail.messagingengine.com>
References: <CAHC+rVFAMn1+U9BpLU=YsM_m=VrU3RD=YJJptMr+yftn4vWc_g@mail.gmail.com> <1398979888.28734.112716705.6883081E@webmail.messagingengine.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/khT3hQ-41Hmb-CJ4IACf5YD2HtI
Subject: Re: [imapext] Finding out REAL Drafts folder on an IMAP Server.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 08:12:41 -0000

On Thursday, 1 May 2014 23:31:28 CEST, Bron Gondwana wrote:
> Alternatively, it looks like running a LIST command and=20
> matching on the word 'draft' will probably let you make a pretty=20
> good guess.

...unless your user happened to use a non-English locale, or prefers=20
localized mailbox names, in which case you're screwed. It's "Koncepty" in=20
Czech, for example.

With kind regards,
Jan

--=20
Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/


From nobody Mon May  5 04:29:42 2014
Return-Path: <brong@fastmail.fm>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514341A02D7 for <imapext@ietfa.amsl.com>; Mon,  5 May 2014 04:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 vuaXRT29aJ-I for <imapext@ietfa.amsl.com>; Mon,  5 May 2014 04:29:38 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id AB4511A02D2 for <imapext@ietf.org>; Mon,  5 May 2014 04:29:38 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D81AC20E9A for <imapext@ietf.org>; Mon,  5 May 2014 07:29:34 -0400 (EDT)
Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Mon, 05 May 2014 07:29:34 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= SiO+rQyMsMwZzrZ13QY7JGIoER0=; b=dJxmVZ+XT20KwqmQkk8XX9QlzblWmsPv OAIThPZUXmC6NSJ7MhtgCzAWn+s7vYzvglZq17S8sx6dW7WPHzzx8YKAYvh6HBTo 5JNp+zrcLOPiPPaiQGLaWqRil6D11WBNOTOXeeM7BKIj8nbAQdG8y+4PyooiMfbB m+kiet4c2hM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=SiO+rQyMsMwZzrZ13QY7JGIoER0=; b=m9XAL JsKpu3EnG2AzAQW+hUrdtSz3fSQ8tnzjjidcm3ZWMK2lKsvQGFdYHTUjS/5c+Uer RnMPIGgFJeIuGQ+EPvyQF1PgmJ2p2FmYjDJYjnVeblIKKI3XOa0A3rvHigIheZ7m jPUCLb+ngxJtFWLmWa8/glaXEhwkraBGgiZqPg=
Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id BB59814401A; Mon,  5 May 2014 07:29:34 -0400 (EDT)
Message-Id: <1399289374.12812.113746145.3335F7E4@webmail.messagingengine.com>
X-Sasl-Enc: nr5Cps5UxDs4wAAv0TJXgk5LpiGLWUpMk3b5oLOWpZtu 1399289374
From: Bron Gondwana <brong@fastmail.fm>
To: imapext@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-48e7952a
Date: Mon, 05 May 2014 21:29:34 +1000
In-Reply-To: <954d4cb5-91a5-4c5d-9876-b77b310f4a9c@flaska.net>
References: <CAHC+rVFAMn1+U9BpLU=YsM_m=VrU3RD=YJJptMr+yftn4vWc_g@mail.gmail.com> <1398979888.28734.112716705.6883081E@webmail.messagingengine.com> <954d4cb5-91a5-4c5d-9876-b77b310f4a9c@flaska.net>
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/SvAc69qvYcj1l4hK2oRQL6xltqM
Subject: Re: [imapext] Finding out REAL Drafts folder on an IMAP Server.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 11:29:40 -0000

On Mon, May 5, 2014, at 06:12 PM, Jan Kundr=E1t wrote:
> On Thursday, 1 May 2014 23:31:28 CEST, Bron Gondwana wrote:
> > Alternatively, it looks like running a LIST command and=20
> > matching on the word 'draft' will probably let you make a pretty=20
> > good guess.
>=20
> ...unless your user happened to use a non-English locale, or prefers=20
> localized mailbox names, in which case you're screwed. It's "Koncepty" in=
=20
> Czech, for example.

https://developers.google.com/translate/v2/getting_started

;)

--=20
  Bron Gondwana
  brong@fastmail.fm


From nobody Tue May  6 05:53:30 2014
Return-Path: <fanf2@hermes.cam.ac.uk>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707BD1A02FE for <imapext@ietfa.amsl.com>; Tue,  6 May 2014 05:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.151
X-Spam-Level: 
X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 bBj7hxK0Q-iA for <imapext@ietfa.amsl.com>; Tue,  6 May 2014 05:53:27 -0700 (PDT)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f50]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE4D1A02F0 for <imapext@ietf.org>; Tue,  6 May 2014 05:53:26 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45468) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Whes5-0005RO-sX (Exim 4.82_3-c0e5623) for imapext@ietf.org (return-path <fanf2@hermes.cam.ac.uk>); Tue, 06 May 2014 13:53:21 +0100
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Whes5-0004io-Rz (Exim 4.72) for imapext@ietf.org (return-path <fanf2@hermes.cam.ac.uk>); Tue, 06 May 2014 13:53:21 +0100
Date: Tue, 6 May 2014 13:53:21 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: imapext@ietf.org
In-Reply-To: <53629677.7040800@pscs.co.uk>
Message-ID: <alpine.LSU.2.00.1405061351340.1509@hermes-1.csi.cam.ac.uk>
References: <CAHC+rVFAMn1+U9BpLU=YsM_m=VrU3RD=YJJptMr+yftn4vWc_g@mail.gmail.com> <53629677.7040800@pscs.co.uk>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/2vC_uHUHsePP54B_jggXWCicU7c
Subject: Re: [imapext] Finding out REAL Drafts folder on an IMAP Server.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 12:53:29 -0000

Paul Smith <paul@pscs.co.uk> wrote:
>
> There is RFC 6154 (http://tools.ietf.org/html/rfc6154) but that's an optional
> extension.
>
> Other than that, you have to guess.

There is a caveat that MUAs tend to make assumptions about the format of
draft messages, so partially composing a message with one MUA then editing
it with another might not lead to a result that makes any sense.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
North Faeroes, South-east Iceland: Southeasterly 3 or 4, backing northeasterly
5 to 7 later. Moderate or rough. Occasional rain. Moderate or good,
occasionally poor.


From nobody Tue May  6 11:16:48 2014
Return-Path: <nigarsultana_n@yahoo.co.in>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761191A023A for <imapext@ietfa.amsl.com>; Tue,  6 May 2014 11:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.702
X-Spam-Level: 
X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 wloVM1My0l2v for <imapext@ietfa.amsl.com>; Tue,  6 May 2014 11:16:41 -0700 (PDT)
Received: from nm49.bullet.mail.ne1.yahoo.com (nm49.bullet.mail.ne1.yahoo.com [98.138.120.56]) by ietfa.amsl.com (Postfix) with SMTP id 0241E1A0269 for <imapext@ietf.org>; Tue,  6 May 2014 11:16:40 -0700 (PDT)
Received: from [127.0.0.1] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 06 May 2014 18:16:37 -0000
Received: from [98.138.100.111] by nm49.bullet.mail.ne1.yahoo.com with NNFMP;  06 May 2014 18:13:41 -0000
Received: from [106.10.166.124] by tm100.bullet.mail.ne1.yahoo.com with NNFMP;  06 May 2014 18:13:41 -0000
Received: from [106.10.151.250] by tm13.bullet.mail.sg3.yahoo.com with NNFMP;  06 May 2014 18:13:40 -0000
Received: from [127.0.0.1] by omp1021.mail.sg3.yahoo.com with NNFMP; 06 May 2014 18:13:40 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 906614.95590.bm@omp1021.mail.sg3.yahoo.com
Received: (qmail 97852 invoked by uid 60001); 6 May 2014 18:13:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024;  t=1399400020; bh=10iCqK0M7UfTdfx6qU+TNgbwGu4BQtPvGCI47BGzvNY=;  h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;  b=ZplRD1UpIA2469xif4fAXWVZ2XZEOnf6FXsaHlUFejTvy/vlnmxH1mxHytIglKDPmgo104klbD/jRMl8N3ng6GF5xip0WEmpEU4rR87Z6Fd2jbpmN0DAzmeZoZnY1Z1pNDa+z0xUlM4ESJQvBxW4pHt4pelqBxfCw4nGec7MnP0=
X-YMail-OSG: ImYPxWgVM1ndcpuvvotpFCsMoEgFA8rxluhrSqzRSQgcLGo oNiFvSswhxhkCC_85Jx2lqZjKOMGPtuI_tyfmMfpmKAr64E.TjLqtno97yP0 StFnYGj6hBZK2R29Y6y28L0cVG9yaDZqqOHl.1MtgJOOsMuwZVoJBYsLKNFx YB76mHGl77ura1eTFvX6JZkDM8dc6jU_IhFPPK0HrKouJdMFtDjRtlOdHDVY 0N5jiv.X6SMsYhuAKVJNHhdIgDSD_XQE.K1QihXRTB0J68bEB1hjs1EF2xlT fcIIRcdZVEcBm1JxFLmSB5YCGQCXT0J0feTJwmAceMSbPIES5Bm1kHAzO1OY g8dH8vFB83kTV70hrvqxM5NXgkQdF0n8PaPbIdLIUmZDUOP7r8xxWL5_.VpP gF6obQzuaAlKJMYVWwLIITLcWGcVVn_Ywmbb_mOXhn8HEuLg.2jqNeuenUQb Ip1NFf651CanR.OcBtV0t.94enqUXAEc.WpOH0efRAWpfaEkiRECKXAHx5RY 7asfDh0MaCDrdjvLP75WVcvPz8vaNm1t7jXZ4.tN5k3Q9C7Kd1_F26VSYyzb 0gcFDRb7ZPCP96Q--
Received: from [106.216.144.87] by web190601.mail.sg3.yahoo.com via HTTP; Wed, 07 May 2014 02:13:40 SGT
X-Rocket-MIMEInfo: 002.001, SGVsbG8gQWxsLAoKVGhlIHVuZGVyc3RhbmRpbmcgZnJvbSBSRkM1MTYyIGlzIHJlc3BvbnNlIHRvIFFSRVNZTkMgb24gc2VsZWN0ZWQgbWFpbGJveCByZXR1cm5zIHRoZSBzdGF0dXMgb2Ygb2xkIG1lc3NhZ2Ugd2hpY2ggaXMgbW9kaWZpZWQuwqAKClRoZXJlIGFyZSBmZXcgY2FzZSBmb3Igd2hpY2ggaSBkaWQgbm90IGdvdCBtdWNoIGluZm8gaW4gUkZDNTE2MjrCoAoxLiBJZiB0aGUgc3RhdGUgb2YgdGhlIG9sZCBtZXNzYWdlIGlzIG5vdCBjaGFuZ2VkIGJ1dCB0aGVyZSBhcmUgc29tZSBuZXcgbWVzc2FnZXMBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.188.663
Message-ID: <1399400020.73819.YahooMailNeo@web190601.mail.sg3.yahoo.com>
Date: Wed, 7 May 2014 02:13:40 +0800 (SGT)
From: Nigar Sultana <nigarsultana_n@yahoo.co.in>
To: "imapext@ietf.org" <imapext@ietf.org>, "imapext@ietfa.amsl.com" <imapext@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1762912605-1310728700-1399400020=:73819"
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/3IiElopy9WORtVCmzEos4XTGG98
Subject: [imapext] Identifying new message from QRESYNC RFC5162
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Nigar Sultana <nigarsultana_n@yahoo.co.in>
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 18:16:45 -0000

---1762912605-1310728700-1399400020=:73819
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello All,=0A=0AThe understanding from RFC5162 is response to QRESYNC on se=
lected mailbox returns the status of old message which is modified.=A0=0A=
=0AThere are few case for which i did not got much info in RFC5162:=A0=0A1.=
 If the state of the old message is not changed but there are some new mess=
ages. The query is:=A0Should server intimate the recent message UID informa=
tion to client?=A0=0A=0A2. If the state of the old message is changed but t=
heir are no new messages. -- The understanding is server returns the UID of=
 old message which has the flag/state changes=0A=0A3. IF the state of the o=
ld message is changes and there are some new message. The query is: should =
server intimate the recent messages UID information to client?=0A=0ARegards=
=0ANigar Sultana
---1762912605-1310728700-1399400020=:73819
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:10pt"><div>Hello All,</div>=
<div><span style=3D"background-color: transparent;"><br></span></div><div s=
tyle=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman=
', 'new york', times, serif; background-color: transparent; font-style: nor=
mal;"><span style=3D"background-color: transparent;">The understanding from=
 RFC5162 is response to QRESYNC on selected mailbox returns the status of o=
ld message which is modified.&nbsp;</span></div><div style=3D"color: rgb(0,=
 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times,=
 serif; background-color: transparent; font-style: normal;"><br></div><div =
style=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roma=
n', 'new york', times, serif; background-color: transparent; font-style: no=
rmal;">There are few case for which i did not got much info in
 RFC5162:&nbsp;</div><div style=3D"color: rgb(0, 0, 0); font-size: 13px; fo=
nt-family: 'times new roman', 'new york', times, serif; background-color: t=
ransparent; font-style: normal;"><span style=3D"background-color: transpare=
nt;">1. If the state of the old message is not changed but there are some n=
ew messages. The query is:&nbsp;</span><span style=3D"background-color: tra=
nsparent;">Should server intimate the recent message UID information to cli=
ent?&nbsp;</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 13px; =
font-family: 'times new roman', 'new york', times, serif; background-color:=
 transparent; font-style: normal;"><span style=3D"background-color: transpa=
rent;"><br></span></div><div style=3D"color: rgb(0, 0, 0); font-size: 13px;=
 font-family: 'times new roman', 'new york', times, serif; background-color=
: transparent; font-style: normal;"><span style=3D"background-color: transp=
arent;">2. If the state of the old message is changed but their are no new
 messages. -- The understanding is server returns the UID of old message wh=
ich has the flag/state changes</span></div><div style=3D"color: rgb(0, 0, 0=
); font-size: 13px; font-family: 'times new roman', 'new york', times, seri=
f; background-color: transparent; font-style: normal;"><span style=3D"backg=
round-color: transparent;"><br></span></div><div style=3D"color: rgb(0, 0, =
0); font-size: 13px; font-family: 'times new roman', 'new york', times, ser=
if; background-color: transparent; font-style: normal;"><span style=3D"back=
ground-color: transparent;">3. IF the state of the old message is changes a=
nd there are some new message. The query is: should server intimate the rec=
ent messages UID information to client?</span></div><div style=3D"color: rg=
b(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', ti=
mes, serif; background-color: transparent; font-style: normal;"><span style=
=3D"background-color: transparent;"><br></span></div><div style=3D"color: r=
gb(0,
 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times,=
 serif; background-color: transparent; font-style: normal;"><span style=3D"=
background-color: transparent;">Regards</span></div><div style=3D"color: rg=
b(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', ti=
mes, serif; background-color: transparent; font-style: normal;"><span style=
=3D"background-color: transparent;">Nigar Sultana</span></div><div style=3D=
"color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new=
 york', times, serif; background-color: transparent; font-style: normal;"><=
span style=3D"background-color: transparent;">&nbsp;&nbsp;</span></div></di=
v></body></html>
---1762912605-1310728700-1399400020=:73819--


From nobody Tue May  6 11:16:51 2014
Return-Path: <nigarsultana_n@yahoo.co.in>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB9E1A02DB for <imapext@ietfa.amsl.com>; Tue,  6 May 2014 11:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable
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 0wfpCey0zhgK for <imapext@ietfa.amsl.com>; Tue,  6 May 2014 11:16:48 -0700 (PDT)
Received: from nm38.bullet.mail.ne1.yahoo.com (nm38.bullet.mail.ne1.yahoo.com [98.138.229.31]) by ietfa.amsl.com (Postfix) with ESMTP id 80DA81A02D3 for <imapext@ietfa.amsl.com>; Tue,  6 May 2014 11:16:48 -0700 (PDT)
Received: from [127.0.0.1] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 06 May 2014 18:16:43 -0000
Received: from [98.138.100.114] by nm38.bullet.mail.ne1.yahoo.com with NNFMP;  06 May 2014 18:13:43 -0000
Received: from [106.10.166.123] by tm105.bullet.mail.ne1.yahoo.com with NNFMP;  06 May 2014 18:13:41 -0000
Received: from [106.10.151.251] by tm12.bullet.mail.sg3.yahoo.com with NNFMP;  06 May 2014 18:13:34 -0000
Received: from [127.0.0.1] by omp1022.mail.sg3.yahoo.com with NNFMP; 06 May 2014 18:13:40 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 882676.31200.bm@omp1022.mail.sg3.yahoo.com
Received: (qmail 97852 invoked by uid 60001); 6 May 2014 18:13:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024;  t=1399400020; bh=10iCqK0M7UfTdfx6qU+TNgbwGu4BQtPvGCI47BGzvNY=;  h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;  b=ZplRD1UpIA2469xif4fAXWVZ2XZEOnf6FXsaHlUFejTvy/vlnmxH1mxHytIglKDPmgo104klbD/jRMl8N3ng6GF5xip0WEmpEU4rR87Z6Fd2jbpmN0DAzmeZoZnY1Z1pNDa+z0xUlM4ESJQvBxW4pHt4pelqBxfCw4nGec7MnP0=
X-YMail-OSG: ImYPxWgVM1ndcpuvvotpFCsMoEgFA8rxluhrSqzRSQgcLGo oNiFvSswhxhkCC_85Jx2lqZjKOMGPtuI_tyfmMfpmKAr64E.TjLqtno97yP0 StFnYGj6hBZK2R29Y6y28L0cVG9yaDZqqOHl.1MtgJOOsMuwZVoJBYsLKNFx YB76mHGl77ura1eTFvX6JZkDM8dc6jU_IhFPPK0HrKouJdMFtDjRtlOdHDVY 0N5jiv.X6SMsYhuAKVJNHhdIgDSD_XQE.K1QihXRTB0J68bEB1hjs1EF2xlT fcIIRcdZVEcBm1JxFLmSB5YCGQCXT0J0feTJwmAceMSbPIES5Bm1kHAzO1OY g8dH8vFB83kTV70hrvqxM5NXgkQdF0n8PaPbIdLIUmZDUOP7r8xxWL5_.VpP gF6obQzuaAlKJMYVWwLIITLcWGcVVn_Ywmbb_mOXhn8HEuLg.2jqNeuenUQb Ip1NFf651CanR.OcBtV0t.94enqUXAEc.WpOH0efRAWpfaEkiRECKXAHx5RY 7asfDh0MaCDrdjvLP75WVcvPz8vaNm1t7jXZ4.tN5k3Q9C7Kd1_F26VSYyzb 0gcFDRb7ZPCP96Q--
Received: from [106.216.144.87] by web190601.mail.sg3.yahoo.com via HTTP; Wed, 07 May 2014 02:13:40 SGT
X-Rocket-MIMEInfo: 002.001, SGVsbG8gQWxsLAoKVGhlIHVuZGVyc3RhbmRpbmcgZnJvbSBSRkM1MTYyIGlzIHJlc3BvbnNlIHRvIFFSRVNZTkMgb24gc2VsZWN0ZWQgbWFpbGJveCByZXR1cm5zIHRoZSBzdGF0dXMgb2Ygb2xkIG1lc3NhZ2Ugd2hpY2ggaXMgbW9kaWZpZWQuwqAKClRoZXJlIGFyZSBmZXcgY2FzZSBmb3Igd2hpY2ggaSBkaWQgbm90IGdvdCBtdWNoIGluZm8gaW4gUkZDNTE2MjrCoAoxLiBJZiB0aGUgc3RhdGUgb2YgdGhlIG9sZCBtZXNzYWdlIGlzIG5vdCBjaGFuZ2VkIGJ1dCB0aGVyZSBhcmUgc29tZSBuZXcgbWVzc2FnZXMBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.188.663
Message-ID: <1399400020.73819.YahooMailNeo@web190601.mail.sg3.yahoo.com>
Date: Wed, 7 May 2014 02:13:40 +0800 (SGT)
From: Nigar Sultana <nigarsultana_n@yahoo.co.in>
To: "imapext@ietf.org" <imapext@ietf.org>, "imapext@ietfa.amsl.com" <imapext@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1762912605-1310728700-1399400020=:73819"
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/3IiElopy9WORtVCmzEos4XTGG98
Subject: [imapext] Identifying new message from QRESYNC RFC5162
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Nigar Sultana <nigarsultana_n@yahoo.co.in>
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 18:16:49 -0000

---1762912605-1310728700-1399400020=:73819
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello All,=0A=0AThe understanding from RFC5162 is response to QRESYNC on se=
lected mailbox returns the status of old message which is modified.=A0=0A=
=0AThere are few case for which i did not got much info in RFC5162:=A0=0A1.=
 If the state of the old message is not changed but there are some new mess=
ages. The query is:=A0Should server intimate the recent message UID informa=
tion to client?=A0=0A=0A2. If the state of the old message is changed but t=
heir are no new messages. -- The understanding is server returns the UID of=
 old message which has the flag/state changes=0A=0A3. IF the state of the o=
ld message is changes and there are some new message. The query is: should =
server intimate the recent messages UID information to client?=0A=0ARegards=
=0ANigar Sultana
---1762912605-1310728700-1399400020=:73819
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:10pt"><div>Hello All,</div>=
<div><span style=3D"background-color: transparent;"><br></span></div><div s=
tyle=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman=
', 'new york', times, serif; background-color: transparent; font-style: nor=
mal;"><span style=3D"background-color: transparent;">The understanding from=
 RFC5162 is response to QRESYNC on selected mailbox returns the status of o=
ld message which is modified.&nbsp;</span></div><div style=3D"color: rgb(0,=
 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times,=
 serif; background-color: transparent; font-style: normal;"><br></div><div =
style=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roma=
n', 'new york', times, serif; background-color: transparent; font-style: no=
rmal;">There are few case for which i did not got much info in
 RFC5162:&nbsp;</div><div style=3D"color: rgb(0, 0, 0); font-size: 13px; fo=
nt-family: 'times new roman', 'new york', times, serif; background-color: t=
ransparent; font-style: normal;"><span style=3D"background-color: transpare=
nt;">1. If the state of the old message is not changed but there are some n=
ew messages. The query is:&nbsp;</span><span style=3D"background-color: tra=
nsparent;">Should server intimate the recent message UID information to cli=
ent?&nbsp;</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 13px; =
font-family: 'times new roman', 'new york', times, serif; background-color:=
 transparent; font-style: normal;"><span style=3D"background-color: transpa=
rent;"><br></span></div><div style=3D"color: rgb(0, 0, 0); font-size: 13px;=
 font-family: 'times new roman', 'new york', times, serif; background-color=
: transparent; font-style: normal;"><span style=3D"background-color: transp=
arent;">2. If the state of the old message is changed but their are no new
 messages. -- The understanding is server returns the UID of old message wh=
ich has the flag/state changes</span></div><div style=3D"color: rgb(0, 0, 0=
); font-size: 13px; font-family: 'times new roman', 'new york', times, seri=
f; background-color: transparent; font-style: normal;"><span style=3D"backg=
round-color: transparent;"><br></span></div><div style=3D"color: rgb(0, 0, =
0); font-size: 13px; font-family: 'times new roman', 'new york', times, ser=
if; background-color: transparent; font-style: normal;"><span style=3D"back=
ground-color: transparent;">3. IF the state of the old message is changes a=
nd there are some new message. The query is: should server intimate the rec=
ent messages UID information to client?</span></div><div style=3D"color: rg=
b(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', ti=
mes, serif; background-color: transparent; font-style: normal;"><span style=
=3D"background-color: transparent;"><br></span></div><div style=3D"color: r=
gb(0,
 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times,=
 serif; background-color: transparent; font-style: normal;"><span style=3D"=
background-color: transparent;">Regards</span></div><div style=3D"color: rg=
b(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', ti=
mes, serif; background-color: transparent; font-style: normal;"><span style=
=3D"background-color: transparent;">Nigar Sultana</span></div><div style=3D=
"color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new=
 york', times, serif; background-color: transparent; font-style: normal;"><=
span style=3D"background-color: transparent;">&nbsp;&nbsp;</span></div></di=
v></body></html>
---1762912605-1310728700-1399400020=:73819--


From nobody Tue May  6 18:02:46 2014
Return-Path: <brong@fastmail.fm>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5871A03F8 for <imapext@ietfa.amsl.com>; Tue,  6 May 2014 18:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 ZAX6b9k7YOSp for <imapext@ietfa.amsl.com>; Tue,  6 May 2014 18:02:42 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id A76DF1A03D4 for <imapext@ietf.org>; Tue,  6 May 2014 18:02:42 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AD981213BF for <imapext@ietf.org>; Tue,  6 May 2014 21:02:37 -0400 (EDT)
Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Tue, 06 May 2014 21:02:37 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= J0uvJi0BHO7sGIKuCu86giQoj+w=; b=OAV64XkScRwCLSpx8eWmz1PsaXjqyuWj pYvzkv9eKlNt4d//DusDMZBiFhy8XtzRmxWrs8gNT7apWhZ3kAq/CoN1OUWKubvf Wnvuwzx8tk3rlllcwKnImhI2IemT+zwrJ6IVIQ+I05wWiZnEhwRn3TKmGchpyB5q R8fbDgGxMQE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=J0uvJi0BHO7sGIKuCu86giQoj+w=; b=tCR /fpcSd5uXIyFui+qjTTxhnDIxvZEkJzmho8YAT9jdpxBT6ZuDepx68uqmUDqLO8W OaXR1eBSoS7zE2pL1c1hgb8fsJwADw68GnM2Jr7qHGx+/a8UpGHbg/EIuKalUIe+ EGanxDKqY2TXVxVNxBCU8nZvOVRtbuzS2YOAyFzo=
Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id 8E20E54105D; Tue,  6 May 2014 21:02:37 -0400 (EDT)
Message-Id: <1399424557.20662.114471321.30F3BBCD@webmail.messagingengine.com>
X-Sasl-Enc: WWkqTiBUcJx8h1Kim4nlQwuVJ8c4GYjT4Qi4LVcV6W+M 1399424557
From: Bron Gondwana <brong@fastmail.fm>
To: imapext@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_1399424557206622";  charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-48e7952a
In-Reply-To: <1399400020.73819.YahooMailNeo@web190601.mail.sg3.yahoo.com>
References: <1399400020.73819.YahooMailNeo@web190601.mail.sg3.yahoo.com>
Date: Wed, 07 May 2014 11:02:37 +1000
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/fo1QBwf_LJAMhoctijbCE4d-exM
Subject: Re: [imapext] Identifying new message from QRESYNC RFC5162
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 01:02:44 -0000

This is a multi-part message in MIME format.

--_----------=_1399424557206622
Content-Transfer-Encoding: 7bit
Content-Type: text/plain

On Wed, May 7, 2014, at 04:13 AM, Nigar Sultana wrote:

Hello All,

The understanding from RFC5162 is response to QRESYNC on selected
mailbox returns the status of old message which is modified.

There are few case for which i did not got much info in RFC5162:
1. If the state of the old message is not changed but there are some
new messages. The query is: Should server intimate the recent message
UID information to client?

2. If the state of the old message is changed but their are no new
messages. -- The understanding is server returns the UID of old message
which has the flag/state changes

3. IF the state of the old message is changes and there are some new
message. The query is: should server intimate the recent messages UID
information to client?


I am struggling to understand what you are asking.

The response to a SELECT QRESYNC:

[1]http://tools.ietf.org/html/rfc5162#section-3.1

If no UID range is provided, then ALL changed messages must have their
information sent to the client.  This includes both old messages which
have flag/state changes, and all new messages.

If a UID range (optional parameter number 3) is provided, then exactly
the same information is sent (all old with changes, and all new) - but
only for the range of UIDs which was given.

The "known UID to MSGNO" map (the 4th optional parameter) is the
confusing part.  All it does is save a server with incomplete
information from needing to send some extra VANISHED (EARLIER)
responses.  It doesn't change which flags need to be sent.

I hope that helps you.

Regards,
Bron.

--
Bron Gondwana
brong@fastmail.fm

References

1. http://tools.ietf.org/html/rfc5162#section-3.1

--_----------=_1399424557206622
Content-Transfer-Encoding: 7bit
Content-Type: text/html

<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Wed, May 7, 2014, at 04:13 AM, Nigar Sultana wrote:<br></div>
<blockquote type="cite"><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:10pt"><div>Hello All,<br></div>
<div>&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><span style="background-color: transparent" class="highlight">The understanding from RFC5162 is response to QRESYNC on selected mailbox returns the status of old message which is modified.&nbsp;</span><br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">There are few case for which i did not got much info in
 RFC5162:&nbsp;<br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><span style="background-color: transparent" class="highlight">1. If the state of the old message is not changed but there are some new messages. The query is:&nbsp;</span><span style="background-color: transparent" class="highlight">Should server intimate the recent message UID information to client?&nbsp;</span><br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><span style="background-color: transparent" class="highlight">2. If the state of the old message is changed but their are no new
 messages. -- The understanding is server returns the UID of old message which has the flag/state changes</span><br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><span style="background-color: transparent" class="highlight">3. IF the state of the old message is changes and there are some new message. The query is: should server intimate the recent messages UID information to client?</span><br></div>
</div>
</blockquote><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:10pt"><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">I am struggling to understand what you are asking.<br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">The response to a SELECT QRESYNC:<br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><a href="http://tools.ietf.org/html/rfc5162#section-3.1">http://tools.ietf.org/html/rfc5162#section-3.1</a><br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">If no UID range is provided, then ALL changed messages must have their information sent to the client.&nbsp; This includes both old messages which have flag/state changes, and all new messages.<br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">If a UID range (optional parameter number 3) is provided, then exactly the same information is sent (all old with changes, and all new) - but only for the range of UIDs which was given.<br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">The "known UID to MSGNO" map (the 4th optional parameter) is the confusing part.&nbsp; All it does is save a server with incomplete information from needing to send some extra VANISHED (EARLIER) responses.&nbsp; It doesn't change which flags need to be sent.<br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">I hope that helps you.<br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">Regards,<br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><br>Bron.<br></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">&nbsp;</div>
</div>
<div id="sig567075"><div class="signature">--<br></div>
<div class="signature">Bron Gondwana<br></div>
<div class="signature">brong@fastmail.fm<br></div>
<div class="signature">&nbsp;</div>
</div>
</body>
</html>

--_----------=_1399424557206622--


From nobody Wed May  7 12:27:12 2014
Return-Path: <j.sb@sta.samsung.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C301A08D4 for <imapext@ietfa.amsl.com>; Wed,  7 May 2014 12:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable
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 AgC9y5FLYaU6 for <imapext@ietfa.amsl.com>; Wed,  7 May 2014 12:27:07 -0700 (PDT)
Received: from cuda4.sta.samsung.com (mailedge.sta.samsung.com [63.166.115.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0984C1A08C8 for <imapext@ietf.org>; Wed,  7 May 2014 12:27:07 -0700 (PDT)
X-ASG-Debug-ID: 1399490821-056fcf6f517c780001-Ao1j2H
Received: from exHub2.telecom.sna.samsung.com ([105.52.12.243]) by cuda4.sta.samsung.com with ESMTP id iJPm98oBihWPY5xu; Wed, 07 May 2014 14:27:01 -0500 (CDT)
X-Barracuda-Envelope-From: j.sb@sta.samsung.com
X-Barracuda-RBL-Trusted-Forwarder: 105.52.12.243
X-ASG-Whitelist: Client
Received: from EXMB5.telecom.sna.samsung.com ([fe80::5f4:56d9:ea68:f480]) by exHub2.telecom.sna.samsung.com ([2002:6934:cf3::6934:cf3]) with mapi id 14.03.0146.000; Wed, 7 May 2014 14:27:01 -0500
From: Jayantheesh S B <j.sb@sta.samsung.com>
X-Barracuda-BWL-IP: fe80::5f4:56d9:ea68:f480
To: "'lemonade@ietf.org'" <lemonade@ietf.org>, "'imapext@ietf.org'" <imapext@ietf.org>
Thread-Topic: [Lemonade] Copy mails from SMTP server to IMAP "Sent" folder
X-ASG-Orig-Subj: [Lemonade] Copy mails from SMTP server to IMAP "Sent" folder
Thread-Index: Ac9qKf4Wx6ml9tsyRXaVGY1ExbUGRw==
Date: Wed, 7 May 2014 19:27:00 +0000
Message-ID: <02454F842DD7B449B96715A2AD90C0361A156880@exMB5.telecom.sna.samsung.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [105.52.12.197]
Content-Type: multipart/alternative; boundary="_000_02454F842DD7B449B96715A2AD90C0361A156880exMB5telecomsna_"
MIME-Version: 1.0
X-Barracuda-Connect: UNKNOWN[105.52.12.243]
X-Barracuda-Start-Time: 1399490821
X-Barracuda-URL: http://65.169.250.23:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at sta.samsung.com
X-Barracuda-BRTS-Status: 1
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/f0GzY0knlv52lEkJwIMmmFY9jTo
Cc: "'Alexey Melnikov \(alexey.melnikov@isode.com\)'" <alexey.melnikov@isode.com>, Jayantheesh S B <j.sb@sta.samsung.com>
Subject: [imapext] [Lemonade] Copy mails from SMTP server to IMAP "Sent" folder
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 19:27:09 -0000

--_000_02454F842DD7B449B96715A2AD90C0361A156880exMB5telecomsna_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

While surfing internet for IMAP protocol, from the below link, its mentione=
d that saving the mail in Sent folder for IMAP account can  be avoided
by URLAUTH (RFC 4467<http://tools.ietf.org/html/rfc4467>) and CATENATE (RFC=
 4469<http://tools.ietf.org/html/rfc4469>) in IMAP and BURL (RFC 4468<http:=
//tools.ietf.org/html/rfc4468>) in SMTP-SUBMISSION rfc.

http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol

Unlike some proprietary protocols which combine sending and retrieval opera=
tions, sending a message and saving a copy in a server-side folder with a b=
ase-level IMAP client requires transmitting the message content twice, once=
 to SMTP for delivery and a second time to IMAP to store in a sent mail fol=
der. This is remedied by a set of extensions defined by the IETF LEMONADE W=
orking Group for mobile devices: URLAUTH (RFC 4467<http://tools.ietf.org/ht=
ml/rfc4467>) and CATENATE (RFC 4469<http://tools.ietf.org/html/rfc4469>) in=
 IMAP and BURL (RFC 4468<http://tools.ietf.org/html/rfc4468>) in SMTP-SUBMI=
SSION. POP servers don't support server-side folders so clients have no cho=
ice but to store sent items on the client. Many IMAP clients can be configu=
red to store sent mail in a client-side folder, or to BCC oneself and then =
filter the incoming mail instead of saving a copy in a folder directly. In =
addition to the LEMONADE "trio", Courier Mail Server<http://en.wikipedia.or=
g/wiki/Courier_Mail_Server> offers a non-standard method of sending using I=
MAP by copying an outgoing message to a dedicated outbox folder


Assume, user has sent an email with 5 MB of attachment from Smart Phone, it=
s consuming mobile data twice, since same mail has to be copied to "Sent" f=
older of IMAP account.
For end user, totally more than 10MB is consumed. Please clarify how this c=
an be avoided by using above specified IETF Lemonade standard.
I did not see any section which talks about the Mail copy to IMAP sent fold=
er. Kindly clarify.

Note:  Gmail SMTP server automatically copies the mail in the IMAP server "=
Sent" folder, which saves mobile data for end user.

Regards,
Jay


--_000_02454F842DD7B449B96715A2AD90C0361A156880exMB5telecomsna_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi All,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">While surfing internet for IMAP protocol, from the b=
elow link, its mentioned that saving the mail in Sent folder for IMAP accou=
nt can&nbsp; be avoided
<o:p></o:p></p>
<p class=3D"MsoNormal">by <span style=3D"font-size:10.5pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-hig=
hlight:yellow">
URLAUTH (</span><span style=3D"background:yellow;mso-highlight:yellow"><a h=
ref=3D"http://tools.ietf.org/html/rfc4467"><span style=3D"font-size:10.5pt;=
font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#663366;text-dec=
oration:none">RFC 4467</span></a></span><span style=3D"font-size:10.5pt;fon=
t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:=
yellow;mso-highlight:yellow">)
 and CATENATE (</span><span style=3D"background:yellow;mso-highlight:yellow=
"><a href=3D"http://tools.ietf.org/html/rfc4469"><span style=3D"font-size:1=
0.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#663366;te=
xt-decoration:none">RFC 4469</span></a></span><span style=3D"font-size:10.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;backg=
round:yellow;mso-highlight:yellow">)
 in IMAP and BURL (</span><span style=3D"background:yellow;mso-highlight:ye=
llow"><a href=3D"http://tools.ietf.org/html/rfc4468"><span style=3D"font-si=
ze:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#66336=
6;text-decoration:none">RFC 4468</span></a></span><span style=3D"font-size:=
10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;b=
ackground:yellow;mso-highlight:yellow">)
 in SMTP-SUBMISSION</span><span style=3D"font-size:10.5pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:white"> rfc.
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://en.wikipedia.org/wiki/Internet_Mes=
sage_Access_Protocol">http://en.wikipedia.org/wiki/Internet_Message_Access_=
Protocol</a><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<table class=3D"MsoTableGrid" border=3D"1" cellspacing=3D"0" cellpadding=3D=
"0" style=3D"border-collapse:collapse;border:none">
<tbody>
<tr>
<td width=3D"638" valign=3D"top" style=3D"width:6.65in;border:solid windowt=
ext 1.0pt;padding:0in 5.4pt 0in 5.4pt">
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#252525;background:white">Unlike som=
e proprietary protocols which combine sending and retrieval operations,
<span style=3D"background:yellow;mso-highlight:yellow">sending a message an=
d saving a copy in a server-side folder with a base-level IMAP client requi=
res transmitting the message content twice, once to SMTP for delivery and a=
 second time to IMAP to store in a
 sent mail folder. This is remedied by a set of extensions defined by the I=
ETF LEMONADE Working Group for mobile devices: URLAUTH (</span></span><span=
 style=3D"background:yellow;mso-highlight:yellow"><a href=3D"http://tools.i=
etf.org/html/rfc4467"><span style=3D"font-size:10.5pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:#663366;text-decoration:none">RFC
 4467</span></a></span><span style=3D"font-size:10.5pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highli=
ght:yellow">) and CATENATE (</span><span style=3D"background:yellow;mso-hig=
hlight:yellow"><a href=3D"http://tools.ietf.org/html/rfc4469"><span style=
=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=
olor:#663366;text-decoration:none">RFC
 4469</span></a></span><span style=3D"font-size:10.5pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highli=
ght:yellow">) in IMAP and BURL (</span><span style=3D"background:yellow;mso=
-highlight:yellow"><a href=3D"http://tools.ietf.org/html/rfc4468"><span sty=
le=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;=
;color:#663366;text-decoration:none">RFC
 4468</span></a></span><span style=3D"font-size:10.5pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highli=
ght:yellow">) in SMTP-SUBMISSION</span><span style=3D"font-size:10.5pt;font=
-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:w=
hite">.
 POP servers don't support server-side folders so clients have no choice bu=
t to store sent items on the client. Many IMAP clients can be configured to=
 store sent mail in a client-side folder, or to BCC oneself and then filter=
 the incoming mail instead of saving
 a copy in a folder directly. In addition to the LEMONADE &quot;trio&quot;,=
<span class=3D"apple-converted-space">&nbsp;</span></span><a href=3D"http:/=
/en.wikipedia.org/wiki/Courier_Mail_Server" title=3D"Courier Mail Server"><=
span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-ser=
if&quot;;color:#0B0080;background:white;text-decoration:none">Courier
 Mail Server</span></a><span class=3D"apple-converted-space"><span style=3D=
"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:#252525;background:white">&nbsp;</span></span><span style=3D"font-size:10=
.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;bac=
kground:white">offers
 a non-standard method of sending using IMAP by copying an outgoing message=
 to a dedicated outbox folder</span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Assume, user has sent an email with 5 MB of attachme=
nt from Smart Phone, its consuming mobile data twice, since same mail has t=
o be copied to &#8220;Sent&#8221; folder of IMAP account.<o:p></o:p></p>
<p class=3D"MsoNormal">For end user, totally more than 10MB is consumed. Pl=
ease clarify how this can be avoided by using above specified IETF Lemonade=
 standard.
<o:p></o:p></p>
<p class=3D"MsoNormal">I did not see any section which talks about the Mail=
 copy to IMAP sent folder. Kindly clarify.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Note: &nbsp;Gmail SMTP server automatically copies t=
he mail in the IMAP server &#8220;Sent&#8221; folder, which saves mobile da=
ta for end user.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Regards,<o:p></o:p></p>
<p class=3D"MsoNormal">Jay<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_02454F842DD7B449B96715A2AD90C0361A156880exMB5telecomsna_--


From nobody Wed May  7 13:13:25 2014
Return-Path: <stephan@rename-it.nl>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E451A016C; Wed,  7 May 2014 13:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.455
X-Spam-Level: 
X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=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 jLeBn-0Bouqk; Wed,  7 May 2014 13:13:17 -0700 (PDT)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id C66A81A0398; Wed,  7 May 2014 13:13:14 -0700 (PDT)
Received: from klara.student.utwente.nl ([130.89.162.218]:59226 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <stephan@rename-it.nl>) id 1Wi8D9-0003iH-Sb; Wed, 07 May 2014 22:13:07 +0200
Message-ID: <536A936F.6090602@rename-it.nl>
Date: Wed, 07 May 2014 22:11:27 +0200
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Jayantheesh S B <j.sb@sta.samsung.com>,  "'lemonade@ietf.org'" <lemonade@ietf.org>, "'imapext@ietf.org'" <imapext@ietf.org>
References: <02454F842DD7B449B96715A2AD90C0361A156880@exMB5.telecom.sna.samsung.com>
In-Reply-To: <02454F842DD7B449B96715A2AD90C0361A156880@exMB5.telecom.sna.samsung.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------050701090304050809070001"
X-RenameIT-MailScanner-SpamScore: -2.3 (--)
X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00, HTML_MESSAGE autolearn=ham version=3.3.1
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/qvHARfVaX0NI65R-DjFrKZM9d-w
Subject: Re: [imapext] [Lemonade] Copy mails from SMTP server to IMAP "Sent" folder
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 20:13:20 -0000

This is a multi-part message in MIME format.
--------------050701090304050809070001
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

On 5/7/2014 9:27 PM, Jayantheesh S B wrote:
>
> Hi All,
>
>  
>
> While surfing internet for IMAP protocol, from the below link, its
> mentioned that saving the mail in Sent folder for IMAP account can  be
> avoided
>
> by URLAUTH (RFC 4467 <http://tools.ietf.org/html/rfc4467>) and
> CATENATE (RFC 4469 <http://tools.ietf.org/html/rfc4469>) in IMAP and
> BURL (RFC 4468 <http://tools.ietf.org/html/rfc4468>) in
> SMTP-SUBMISSIONrfc.
>
>  
>
> http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol
>
>  
>
> Unlike some proprietary protocols which combine sending and retrieval
> operations, sending a message and saving a copy in a server-side
> folder with a base-level IMAP client requires transmitting the message
> content twice, once to SMTP for delivery and a second time to IMAP to
> store in a sent mail folder. This is remedied by a set of extensions
> defined by the IETF LEMONADE Working Group for mobile devices: URLAUTH
> (RFC 4467 <http://tools.ietf.org/html/rfc4467>) and CATENATE (RFC 4469
> <http://tools.ietf.org/html/rfc4469>) in IMAP and BURL (RFC 4468
> <http://tools.ietf.org/html/rfc4468>) in SMTP-SUBMISSION. POP servers
> don't support server-side folders so clients have no choice but to
> store sent items on the client. Many IMAP clients can be configured to
> store sent mail in a client-side folder, or to BCC oneself and then
> filter the incoming mail instead of saving a copy in a folder
> directly. In addition to the LEMONADE "trio", Courier Mail Server
> <http://en.wikipedia.org/wiki/Courier_Mail_Server> offers a
> non-standard method of sending using IMAP by copying an outgoing
> message to a dedicated outbox folder
>
>  
>
> Assume, user has sent an email with 5 MB of attachment from Smart
> Phone, its consuming mobile data twice, since same mail has to be
> copied to "Sent" folder of IMAP account.
>
> For end user, totally more than 10MB is consumed. Please clarify how
> this can be avoided by using above specified IETF Lemonade standard.
>
> I did not see any section which talks about the Mail copy to IMAP sent
> folder. Kindly clarify.
>

http://tools.ietf.org/html/rfc5550#section-8

Regards,

Stephan.


--------------050701090304050809070001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      On 5/7/2014 9:27 PM, Jayantheesh S B wrote:<br>
    </div>
    <blockquote
cite="mid:02454F842DD7B449B96715A2AD90C0361A156880@exMB5.telecom.sna.samsung.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:"Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hi All,<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">While surfing internet for IMAP protocol,
          from the below link, its mentioned that saving the mail in
          Sent folder for IMAP account can&nbsp; be avoided
          <o:p></o:p></p>
        <p class="MsoNormal">by <span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highlight:yellow">URLAUTH
            (</span><span style="background:yellow;mso-highlight:yellow"><a
              moz-do-not-send="true"
              href="http://tools.ietf.org/html/rfc4467"><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#663366;text-decoration:none">RFC
                4467</span></a></span><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highlight:yellow">)
            and CATENATE (</span><span
            style="background:yellow;mso-highlight:yellow"><a
              moz-do-not-send="true"
              href="http://tools.ietf.org/html/rfc4469"><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#663366;text-decoration:none">RFC
                4469</span></a></span><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highlight:yellow">)
            in IMAP and BURL (</span><span
            style="background:yellow;mso-highlight:yellow"><a
              moz-do-not-send="true"
              href="http://tools.ietf.org/html/rfc4468"><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#663366;text-decoration:none">RFC
                4468</span></a></span><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highlight:yellow">)
            in SMTP-SUBMISSION</span><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:white">
            rfc.
          </span><o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><a moz-do-not-send="true"
            href="http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol">http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol</a><o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <table class="MsoTableGrid"
          style="border-collapse:collapse;border:none" cellpadding="0"
          cellspacing="0" border="1">
          <tbody>
            <tr>
              <td style="width:6.65in;border:solid windowtext
                1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
                width="638">
                <p class="MsoNormal"><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:white">Unlike
                    some proprietary protocols which combine sending and
                    retrieval operations,
                    <span style="background:yellow;mso-highlight:yellow">sending
                      a message and saving a copy in a server-side
                      folder with a base-level IMAP client requires
                      transmitting the message content twice, once to
                      SMTP for delivery and a second time to IMAP to
                      store in a sent mail folder. This is remedied by a
                      set of extensions defined by the IETF LEMONADE
                      Working Group for mobile devices: URLAUTH (</span></span><span
                    style="background:yellow;mso-highlight:yellow"><a
                      moz-do-not-send="true"
                      href="http://tools.ietf.org/html/rfc4467"><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#663366;text-decoration:none">RFC

                        4467</span></a></span><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highlight:yellow">)
                    and CATENATE (</span><span
                    style="background:yellow;mso-highlight:yellow"><a
                      moz-do-not-send="true"
                      href="http://tools.ietf.org/html/rfc4469"><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#663366;text-decoration:none">RFC

                        4469</span></a></span><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highlight:yellow">)
                    in IMAP and BURL (</span><span
                    style="background:yellow;mso-highlight:yellow"><a
                      moz-do-not-send="true"
                      href="http://tools.ietf.org/html/rfc4468"><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#663366;text-decoration:none">RFC

                        4468</span></a></span><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:yellow;mso-highlight:yellow">)
                    in SMTP-SUBMISSION</span><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:white">.
                    POP servers don't support server-side folders so
                    clients have no choice but to store sent items on
                    the client. Many IMAP clients can be configured to
                    store sent mail in a client-side folder, or to BCC
                    oneself and then filter the incoming mail instead of
                    saving a copy in a folder directly. In addition to
                    the LEMONADE "trio",<span
                      class="apple-converted-space">&nbsp;</span></span><a
                    moz-do-not-send="true"
                    href="http://en.wikipedia.org/wiki/Courier_Mail_Server"
                    title="Courier Mail Server"><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#0B0080;background:white;text-decoration:none">Courier

                      Mail Server</span></a><span
                    class="apple-converted-space"><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:white">&nbsp;</span></span><span
style="font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#252525;background:white">offers

                    a non-standard method of sending using IMAP by
                    copying an outgoing message to a dedicated outbox
                    folder</span><o:p></o:p></p>
              </td>
            </tr>
          </tbody>
        </table>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Assume, user has sent an email with 5 MB of
          attachment from Smart Phone, its consuming mobile data twice,
          since same mail has to be copied to &#8220;Sent&#8221; folder of IMAP
          account.<o:p></o:p></p>
        <p class="MsoNormal">For end user, totally more than 10MB is
          consumed. Please clarify how this can be avoided by using
          above specified IETF Lemonade standard.
          <o:p></o:p></p>
        <p class="MsoNormal">I did not see any section which talks about
          the Mail copy to IMAP sent folder. Kindly clarify.</p>
      </div>
    </blockquote>
    <br>
    <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5550#section-8">http://tools.ietf.org/html/rfc5550#section-8</a><br>
    <br>
    Regards,<br>
    <br>
    Stephan.<br>
    <br>
  </body>
</html>

--------------050701090304050809070001--


From nobody Tue May 13 16:11:10 2014
Return-Path: <stephan@rename-it.nl>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4752A1A0175 for <imapext@ietfa.amsl.com>; Tue, 13 May 2014 16:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.443
X-Spam-Level: *
X-Spam-Status: No, score=1.443 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=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 vG1jiD8jGEpc for <imapext@ietfa.amsl.com>; Tue, 13 May 2014 16:11:07 -0700 (PDT)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id A31251A0130 for <imapext@ietf.org>; Tue, 13 May 2014 16:11:06 -0700 (PDT)
Received: from klara.student.utwente.nl ([130.89.162.218]:54474 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <stephan@rename-it.nl>) id 1WkLqZ-00045B-G8 for imapext@ietf.org; Wed, 14 May 2014 01:10:59 +0200
Message-ID: <5372A643.2030309@rename-it.nl>
Date: Wed, 14 May 2014 01:09:55 +0200
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "'imapext@ietf.org'" <imapext@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-SpamScore: -2.3 (--)
X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/8MoueAjd4-M5p3f7dXIHwi0I_zY
Subject: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 23:11:09 -0000

Hi,

I just noticed that the IMAP METADATA and METADATA-SERVER capabilities
(RFC 5464) are not listed in the IANA IMAP capability registry:

http://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml

Is there a particular reason for that?

Regards,

Stephan.


From nobody Tue May 13 18:14:04 2014
Return-Path: <cyrus@daboo.name>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C03F1A0118 for <imapext@ietfa.amsl.com>; Tue, 13 May 2014 18:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 9bRSp3n5pF3J for <imapext@ietfa.amsl.com>; Tue, 13 May 2014 18:13:58 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id EF3D81A00DC for <imapext@ietf.org>; Tue, 13 May 2014 18:13:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5BD3A6629BD3; Tue, 13 May 2014 21:13:51 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTNSfRfjcCjK; Tue, 13 May 2014 21:13:47 -0400 (EDT)
Received: from [17.45.162.204] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 396AA6629BBA; Tue, 13 May 2014 21:13:47 -0400 (EDT)
Date: Tue, 13 May 2014 21:13:45 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Stephan Bosch <stephan@rename-it.nl>, "'imapext@ietf.org'" <imapext@ietf.org>
Message-ID: <590026B7623FC8DCB35018FD@cyrus.local>
In-Reply-To: <5372A643.2030309@rename-it.nl>
References: <5372A643.2030309@rename-it.nl>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=572
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/-1TWNuCy8BMTm_rE89XmHk5PMVw
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 01:14:02 -0000

Hi Stephan,

--On May 14, 2014 at 1:09:55 AM +0200 Stephan Bosch <stephan@rename-it.nl> 
wrote:

> I just noticed that the IMAP METADATA and METADATA-SERVER capabilities
> (RFC 5464) are not listed in the IANA IMAP capability registry:
>
> http://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml
>
> Is there a particular reason for that?

Looks like the capabilities were not explicitly included in the IANA 
section of 5464 - my mistake - sorry. So this is an oversight. Perhaps 
Barry or Pete can request IANA to update the registry.

-- 
Cyrus Daboo


From nobody Tue May 13 19:06:29 2014
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F011A01E5 for <imapext@ietfa.amsl.com>; Tue, 13 May 2014 19:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 zOTdOpHP8Iyt for <imapext@ietfa.amsl.com>; Tue, 13 May 2014 19:06:24 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 885031A01D6 for <imapext@ietf.org>; Tue, 13 May 2014 19:06:24 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id lf12so1625953vcb.1 for <imapext@ietf.org>; Tue, 13 May 2014 19:06:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KoMiG70SHOUl11BAEFnOwl73WbegeSpcxc9sIb99He4=; b=0yP0SkBNjpu0aAo/2wHkEJF5uEItjQtopJO4R+R/j1JIaYwBPzuMfxw5AIJus/oVGy hGPb2RTWZLVzd+pj696XtYpW2a/W9douGbbBw+faqWWvAO8xKJLKk1SxQMUnhGNf5u96 wZu1W9s+cj51qJlHzHCqab+xWRK1V4k7mxniywRMi6lhJV7SA337mOnnEvIzTimCuaJy dg5e7g/9stKH+f2mBuL6kUdQaxiLnZaf1/OH20dB53aV87CPHYY+3pTXyHTLb74onms9 QwMMMWznJpaEBXKDU8udZttoYTzOsEDuAtzkmusz0E9BMP1mvfsitN8iWND7zKSo2QNT XHxw==
MIME-Version: 1.0
X-Received: by 10.52.185.72 with SMTP id fa8mr404137vdc.12.1400033177885; Tue, 13 May 2014 19:06:17 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.58.33.199 with HTTP; Tue, 13 May 2014 19:06:17 -0700 (PDT)
In-Reply-To: <590026B7623FC8DCB35018FD@cyrus.local>
References: <5372A643.2030309@rename-it.nl> <590026B7623FC8DCB35018FD@cyrus.local>
Date: Tue, 13 May 2014 22:06:17 -0400
X-Google-Sender-Auth: LhO6F4l59-EUAFwIHyeqHDxP64g
Message-ID: <CAC4RtVD7EAXREL5xcamYgyAw-Pk7hjtUQShc6BC0hYG5SA3tHQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Cyrus Daboo <cyrus@daboo.name>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/wr2lyY5cgLJwAnLiLK2P1c-Z3Rs
Cc: Stephan Bosch <stephan@rename-it.nl>, "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 02:06:26 -0000

>> I just noticed that the IMAP METADATA and METADATA-SERVER capabilities
>> (RFC 5464) are not listed in the IANA IMAP capability registry:
>
> Looks like the capabilities were not explicitly included in the IANA section
> of 5464 - my mistake - sorry. So this is an oversight. Perhaps Barry or Pete
> can request IANA to update the registry.

Yeh, I hate it when that happens; everyone missed it -- and both the
shepherd and responsible AD are experienced IMAP people.  These things
happen (and more so with individual submissions, I think, but
whatever...).

The easiest way to deal with this is for Cyrus to write a quick, short
draft like this:

----------------------------------------
1. Introduction [same as the Abstract]

The IMAP METADATA Extension [RFC5464] defined two new IMAP
capabilities -- METADATA and METADATA-SERVER -- but neglected to
register them.  This document corrects that oversight.

2. IANA Considerations

Please register METADATA and METADATA-SERVER in the IMAP Capabilities
registry <http://www.iana.org/assignments/imap-capabilities>, using
the reference [RFC5464].

3. Security Considerations

Making sure everything is registered is a Good Thing(tm).

4. Normative References

RFC5464 ...etc...
----------------------------------------

Really... that short.  Make it Experimental, because the registry
requires that or Stds Trk.  Post it, and immediately send me a
publication request, and I'll sponsor it.  Four week last call, next
telechat, should be done and registered within 6 weeks.  And that
avoids any questions about process.

b


From nobody Tue May 13 19:14:05 2014
Return-Path: <cyrus@daboo.name>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB22B1A01E8 for <imapext@ietfa.amsl.com>; Tue, 13 May 2014 19:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 AGTcR-xymg54 for <imapext@ietfa.amsl.com>; Tue, 13 May 2014 19:14:01 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3EF1A01E4 for <imapext@ietf.org>; Tue, 13 May 2014 19:14:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id DB618662ABC5; Tue, 13 May 2014 22:13:54 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSsFhnhUK1ut; Tue, 13 May 2014 22:13:53 -0400 (EDT)
Received: from [17.45.162.204] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 2183E662ABB9; Tue, 13 May 2014 22:13:52 -0400 (EDT)
Date: Tue, 13 May 2014 22:13:51 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Barry Leiba <barryleiba@computer.org>
Message-ID: <A7D2874065E64D1C05203FB0@cyrus.local>
In-Reply-To: <CAC4RtVD7EAXREL5xcamYgyAw-Pk7hjtUQShc6BC0hYG5SA3tHQ@mail.gmail.com>
References: <5372A643.2030309@rename-it.nl> <590026B7623FC8DCB35018FD@cyrus.local> <CAC4RtVD7EAXREL5xcamYgyAw-Pk7hjtUQShc6BC0hYG5SA3tHQ@mail.gmail.com>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=488
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/jPaEh85MbJO6slGESAtWtFIdvm4
Cc: Stephan Bosch <stephan@rename-it.nl>, imapext@ietf.org
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 02:14:03 -0000

Hi Barry,

--On May 13, 2014 at 10:06:17 PM -0400 Barry Leiba 
<barryleiba@computer.org> wrote:

> The easiest way to deal with this is for Cyrus to write a quick, short
> draft like this:

I don't mind doing that, but is it really necessary? Could we not treat 
this as an erratum? I note that several of the specs currently listed in 
the capabilities registry do not have an IANA section at all (e.g. RFC3502, 
RFC3516) - so some "special" action was taken for those.

-- 
Cyrus Daboo


From nobody Wed May 14 00:25:54 2014
Return-Path: <dave@cridland.net>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D30E1A0273 for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 00:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 j2aR3_nqVOCC for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 00:25:51 -0700 (PDT)
Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 267211A0040 for <imapext@ietf.org>; Wed, 14 May 2014 00:25:51 -0700 (PDT)
Received: by mail-oa0-f48.google.com with SMTP id i4so1721303oah.35 for <imapext@ietf.org>; Wed, 14 May 2014 00:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=un/V4jMP6qHS5HGzWNfubQQSmFyLl/+QfMzn13JdY5I=; b=E7YZZvneA3Nnltm2AaZ0a3EfWEDyeKAYWzqIW+plo7Ugbigxilaw74GHZoaP9fpvmt GZwz9xYd/ROPiR44zcKCLwExDHVg9/M4A8LgDckluvxyyfMbgJULlc7C5lB8RUVEq51k ukbDqkHdbo380LZhHBn+uZp9OUlHCyFg6RxpI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=un/V4jMP6qHS5HGzWNfubQQSmFyLl/+QfMzn13JdY5I=; b=QfO6dcWmDblJDiI9+jsepCiRX13KvtnzFXzP7xfn3XPMChOjZKnIuP6pbJFmotoTPx COV1TYMvJA40lft86y032NvzuHLaKRWj7mVnm0rQTezQfsYba0k/sdXac0GPDXBvzKFx p3Pq2hWQZUY8SsId90mwEOWfPiVFQGfmbXkxXVW//dI7FoGcgTl4yDEvZTnsD7AZZ5g9 NxfLeLFegCKeq3zpg1wfWlvpxyw6O/z7oopMg3RdRrmfGanhol6StCbdi24G1rPWehdn mOmY1F7Ftq5DOqp3J2qpQFomwysEYPwJT5gT9dm1AYyHhvvYuZc01EVCUX05fSXAj7tS yJUA==
X-Gm-Message-State: ALoCoQmp+4swAQqBPsgIMa/JVYBMgcAebYBDG0HKcKnFUm+XyMoWkL5TolyV6ddJAtD6sAL0pKqs
MIME-Version: 1.0
X-Received: by 10.60.179.80 with SMTP id de16mr1657838oec.69.1400052344573; Wed, 14 May 2014 00:25:44 -0700 (PDT)
Received: by 10.60.60.100 with HTTP; Wed, 14 May 2014 00:25:44 -0700 (PDT)
In-Reply-To: <A7D2874065E64D1C05203FB0@cyrus.local>
References: <5372A643.2030309@rename-it.nl> <590026B7623FC8DCB35018FD@cyrus.local> <CAC4RtVD7EAXREL5xcamYgyAw-Pk7hjtUQShc6BC0hYG5SA3tHQ@mail.gmail.com> <A7D2874065E64D1C05203FB0@cyrus.local>
Date: Wed, 14 May 2014 08:25:44 +0100
Message-ID: <CAKHUCzyBQVZRy18GYmF_NUThP1HorqJG2A-GmaorprbWeMJ=5Q@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Cyrus Daboo <cyrus@daboo.name>
Content-Type: multipart/alternative; boundary=089e0118243aaa62df04f957162f
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/EH1iJisuyaKbbt7P2icrIkwZ_po
Cc: Stephan Bosch <stephan@rename-it.nl>, Barry Leiba <barryleiba@computer.org>, "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 07:25:52 -0000

--089e0118243aaa62df04f957162f
Content-Type: text/plain; charset=UTF-8

I think you can just send IANA an email, with the correct form, pointing to
the existing RFC. I don't think the process requires the form be in the
RFC, merely that there's an RFC defining the capability being registered.

Of course, the IESG will need to express their approval, somehow, too.


On 14 May 2014 03:13, Cyrus Daboo <cyrus@daboo.name> wrote:

> Hi Barry,
>
>
> --On May 13, 2014 at 10:06:17 PM -0400 Barry Leiba <
> barryleiba@computer.org> wrote:
>
>  The easiest way to deal with this is for Cyrus to write a quick, short
>> draft like this:
>>
>
> I don't mind doing that, but is it really necessary? Could we not treat
> this as an erratum? I note that several of the specs currently listed in
> the capabilities registry do not have an IANA section at all (e.g. RFC3502,
> RFC3516) - so some "special" action was taken for those.
>
> --
> Cyrus Daboo
>
>
> _______________________________________________
> imapext mailing list
> imapext@ietf.org
> https://www.ietf.org/mailman/listinfo/imapext
>

--089e0118243aaa62df04f957162f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think you can just send IANA an email, with the correct =
form, pointing to the existing RFC. I don&#39;t think the process requires =
the form be in the RFC, merely that there&#39;s an RFC defining the capabil=
ity being registered.<div>
<br></div><div>Of course, the IESG will need to express their approval, som=
ehow, too.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmai=
l_quote">On 14 May 2014 03:13, Cyrus Daboo <span dir=3D"ltr">&lt;<a href=3D=
"mailto:cyrus@daboo.name" target=3D"_blank">cyrus@daboo.name</a>&gt;</span>=
 wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi Barry,<div class=3D""><br>
<br>
--On May 13, 2014 at 10:06:17 PM -0400 Barry Leiba &lt;<a href=3D"mailto:ba=
rryleiba@computer.org" target=3D"_blank">barryleiba@computer.org</a>&gt; wr=
ote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The easiest way to deal with this is for Cyrus to write a quick, short<br>
draft like this:<br>
</blockquote>
<br></div>
I don&#39;t mind doing that, but is it really necessary? Could we not treat=
 this as an erratum? I note that several of the specs currently listed in t=
he capabilities registry do not have an IANA section at all (e.g. RFC3502, =
RFC3516) - so some &quot;special&quot; action was taken for those.<span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><br>

<br>
-- <br>
Cyrus Daboo</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
______________________________<u></u>_________________<br>
imapext mailing list<br>
<a href=3D"mailto:imapext@ietf.org" target=3D"_blank">imapext@ietf.org</a><=
br>
<a href=3D"https://www.ietf.org/mailman/listinfo/imapext" target=3D"_blank"=
>https://www.ietf.org/mailman/<u></u>listinfo/imapext</a><br>
</div></div></blockquote></div><br></div>

--089e0118243aaa62df04f957162f--


From nobody Wed May 14 09:09:06 2014
Return-Path: <stephan@rename-it.nl>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF101A02CC for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 09:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.456
X-Spam-Level: 
X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=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 eNkq7yS6EfbE for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 09:09:03 -0700 (PDT)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7521C1A02CF for <imapext@ietf.org>; Wed, 14 May 2014 09:09:01 -0700 (PDT)
Received: from [217.119.239.130] (port=5218 helo=[192.168.1.117]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <stephan@rename-it.nl>) id 1Wkbjd-00069D-Q4 for imapext@ietf.org; Wed, 14 May 2014 18:08:53 +0200
Message-ID: <53739509.5020304@rename-it.nl>
Date: Wed, 14 May 2014 18:08:41 +0200
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: imapext@ietf.org
References: <5372A643.2030309@rename-it.nl> <590026B7623FC8DCB35018FD@cyrus.local> <CAC4RtVD7EAXREL5xcamYgyAw-Pk7hjtUQShc6BC0hYG5SA3tHQ@mail.gmail.com> <A7D2874065E64D1C05203FB0@cyrus.local> <CAKHUCzyBQVZRy18GYmF_NUThP1HorqJG2A-GmaorprbWeMJ=5Q@mail.gmail.com> <CALaySJLENYD4pfsWCWa+OmNsCQpAeKr=3yyU7qnmPZ-rhcdeRA@mail.gmail.com> <EEDF5181FD7BE63FAC920108@caldav.corp.apple.com>
In-Reply-To: <EEDF5181FD7BE63FAC920108@caldav.corp.apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-SpamScore: -2.3 (--)
X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/PqD5WIIOyR0TpwLqeGmow0kq2qE
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 16:09:05 -0000

(ohw, somehow mailing list got dropped from To:)

Cyrus Daboo schreef op 14-5-2014 17:26:
> OK.
>
> I was going to do a quick scan and see if any other capabilities are
> missing. Here is what I found:
>
> AUTH= (3501) Not sure this is needed given it is in the base spec itself.
>
> URLAUTH=BINARY (5524) - actually this is bad. The spec uses
> "URLAUTH=BINARY" in section 3, but uses "URLFETCH=BINARY" in the IANA
> section (which is registered). However, the Dovecot server I use has
> "URLAUTH=BINARY". I do not see any errata for 5524 so this issue needs
> to be addressed.

Ow. That is quite bad indeed.

We didn't notice that either. Dovecot implementation is based on the ABNF.

I know of at least one other server that supports this capability: Cyrus 
(http://www.imapwiki.org/Specs).

I quickly grepped the source code and, luckily, it uses "URLAUTH=BINARY" 
too.

Still, I wonder whether there are others. The list on the imapwiki is 
far from complete, nor up-to-date.

Isode was involved in writing this RFC, but I don't know whether they 
actually implemented it for their product. Dave?

Regards,

Stephan.


From nobody Wed May 14 10:11:26 2014
Return-Path: <cyrus@daboo.name>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953BC1A02B9 for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 10:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 elM70ygaKTaX for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 10:11:03 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3EA1A02E1 for <imapext@ietf.org>; Wed, 14 May 2014 10:11:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 31EF5663B2D4 for <imapext@ietf.org>; Wed, 14 May 2014 13:10:56 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msb8oEpDhA7z for <imapext@ietf.org>; Wed, 14 May 2014 13:10:54 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id ABA95663B2C3 for <imapext@ietf.org>; Wed, 14 May 2014 13:10:53 -0400 (EDT)
Date: Wed, 14 May 2014 12:08:17 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: imapext@ietf.org
Message-ID: <65E7C5BB55ADC0591730D83C@caldav.corp.apple.com>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=565
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/BrVpK9LWbo2W6oGOrV0YfeOznAM
Subject: [imapext] RFC 5524 - what is the proper capability to use?
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 17:11:14 -0000

Hi,
Whilst researching the issue with missing capabilities in the IANA registry 
I ran into the following: RFC 5524 (Extended URLFETCH for Binary and 
Converted Parts) defines a capability string of "URLAUTH=BINARY" in section 
3 and the ABNF in Section 5. However, the IANA section uses 
"URLFETCH=BINARY", which is what IANA has registered at 
http://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml.

The Dovecot server I use advertises "URLAUTH=BINARY".

So which is correct? What do other servers do? What do clients expect?

-- 
Cyrus Daboo


From nobody Wed May 14 10:14:48 2014
Return-Path: <murch@andrew.cmu.edu>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97311A02CF for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 10:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 UUSPqLmLtfhU for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 10:14:24 -0700 (PDT)
Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.202]) by ietfa.amsl.com (Postfix) with ESMTP id 143B21A02B9 for <imapext@ietf.org>; Wed, 14 May 2014 10:14:24 -0700 (PDT)
Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s4EHEFek000452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <imapext@ietf.org>; Wed, 14 May 2014 13:14:16 -0400
Message-ID: <5373A467.1090903@andrew.cmu.edu>
Date: Wed, 14 May 2014 13:14:15 -0400
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: imapext@ietf.org
References: <65E7C5BB55ADC0591730D83C@caldav.corp.apple.com>
In-Reply-To: <65E7C5BB55ADC0591730D83C@caldav.corp.apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.5.192722
X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_700_799 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0,  __URI_NO_MAILTO 0, __URI_NS , __USER_AGENT 0)
X-SMTP-Spam-Score: 33%
X-Scanned-By: MIMEDefang 2.74 on 128.2.105.202
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/CYPEyz1eq1tym52E28Hwh79d_nw
Subject: Re: [imapext] RFC 5524 - what is the proper capability to use?
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 17:14:33 -0000

On 05/14/2014 12:08 PM, Cyrus Daboo wrote:
> Hi,
> Whilst researching the issue with missing capabilities in the IANA 
> registry I ran into the following: RFC 5524 (Extended URLFETCH for 
> Binary and Converted Parts) defines a capability string of 
> "URLAUTH=BINARY" in section 3 and the ABNF in Section 5. However, the 
> IANA section uses "URLFETCH=BINARY", which is what IANA has registered 
> at 
> http://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml.
>
> The Dovecot server I use advertises "URLAUTH=BINARY".
>
> So which is correct? What do other servers do? What do clients expect?
>

Cyrus IMAP also uses "URLAUTH=BINARY".

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University


From nobody Wed May 14 11:30:07 2014
Return-Path: <j.sb@sta.samsung.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F9E1A0155 for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 11:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 Cn2t8zQJoNcn for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 11:30:03 -0700 (PDT)
Received: from cuda3.sta.samsung.com (mailedge.sta.samsung.com [63.166.115.17]) by ietfa.amsl.com (Postfix) with ESMTP id 075CE1A013C for <imapext@ietf.org>; Wed, 14 May 2014 11:30:02 -0700 (PDT)
X-ASG-Debug-ID: 1400092195-049321106bb5230001-Ao1j2H
Received: from exHub2.telecom.sna.samsung.com ([105.52.12.243]) by cuda3.sta.samsung.com with ESMTP id RI6MVvVh7xnEhk3n; Wed, 14 May 2014 13:29:55 -0500 (CDT)
X-Barracuda-Envelope-From: j.sb@sta.samsung.com
X-Barracuda-RBL-Trusted-Forwarder: 105.52.12.243
X-ASG-Whitelist: Client
Received: from EXMB5.telecom.sna.samsung.com ([fe80::5f4:56d9:ea68:f480]) by exHub2.telecom.sna.samsung.com ([2002:6934:cf3::6934:cf3]) with mapi id 14.03.0146.000; Wed, 14 May 2014 13:29:54 -0500
From: Jayantheesh S B <j.sb@sta.samsung.com>
X-Barracuda-BWL-IP: fe80::5f4:56d9:ea68:f480
To: 'Cyrus Daboo' <cyrus@daboo.name>, 'Barry Leiba' <barryleiba@computer.org>
Thread-Topic: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-ASG-Orig-Subj: RE: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
Thread-Index: AQHPb5gCNDtbSELnVEm+MUrql7mg7JtAZCbg
Date: Wed, 14 May 2014 18:29:54 +0000
Message-ID: <02454F842DD7B449B96715A2AD90C0361A15F031@exMB5.telecom.sna.samsung.com>
References: <5372A643.2030309@rename-it.nl> <590026B7623FC8DCB35018FD@cyrus.local> <CAC4RtVD7EAXREL5xcamYgyAw-Pk7hjtUQShc6BC0hYG5SA3tHQ@mail.gmail.com> <A7D2874065E64D1C05203FB0@cyrus.local>
In-Reply-To: <A7D2874065E64D1C05203FB0@cyrus.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [105.52.12.197]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: UNKNOWN[105.52.12.243]
X-Barracuda-Start-Time: 1400092195
X-Barracuda-URL: http://65.169.250.17:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at sta.samsung.com
X-Barracuda-BRTS-Status: 1
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/x_YnGGjiFXO6nPDBqtV4x23e8b4
Cc: 'Stephan Bosch' <stephan@rename-it.nl>, "'imapext@ietf.org'" <imapext@ietf.org>
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 18:30:04 -0000

Hi Cyrus Daboo,

If you are fine, we would like to contribute for this draft as Barry mentio=
ned.=20

Regards,
Jay
-----Original Message-----
From: Cyrus Daboo [mailto:cyrus@daboo.name]=20
Sent: Tuesday, May 13, 2014 10:14 PM
To: Barry Leiba
Cc: Stephan Bosch; imapext@ietf.org
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capabi=
lity registry.

Hi Barry,

--On May 13, 2014 at 10:06:17 PM -0400 Barry Leiba <barryleiba@computer.org=
> wrote:

> The easiest way to deal with this is for Cyrus to write a quick, short=20
> draft like this:

I don't mind doing that, but is it really necessary? Could we not treat thi=
s as an erratum? I note that several of the specs currently listed in the c=
apabilities registry do not have an IANA section at all (e.g. RFC3502,
RFC3516) - so some "special" action was taken for those.

--
Cyrus Daboo



From nobody Wed May 14 11:58:56 2014
Return-Path: <dave@cridland.net>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51D41A0325 for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 11:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 pqfXRWxTD-6d for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 11:58:44 -0700 (PDT)
Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 51B5E1A035A for <imapext@ietf.org>; Wed, 14 May 2014 11:58:31 -0700 (PDT)
Received: by mail-oa0-f43.google.com with SMTP id l6so2698556oag.16 for <imapext@ietf.org>; Wed, 14 May 2014 11:58:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vBEpIliuifKup5hawGiNd6gLZJtaVbfADMNuqj/IjOc=; b=ezub+yrqKBYD9RatN3iZ+P0v2Zc2UDWZUvFJ1KcI/0AfJDR8KggHCSxpTDH3ZxJgGn J72JVkwRJmXCdxqAoBH0JO3qUg5lHd4TFQSR6sbPX8PHJ2NV8Jf7iHptAsLlyvdfyEPw eOU7P2t7/ZGtCVTBboU628bEPgyuWATP6yRhg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vBEpIliuifKup5hawGiNd6gLZJtaVbfADMNuqj/IjOc=; b=RVvE6ir7KAiH/9dupaZCHDGDwdtio6f1PbFvELJv6xBD7zABsPUqaE6Yz0WlPLgUD5 dDHeWm71PMxh7s5P7zkq5MpYIbI2sjPbCTgI3XLGaDhCa2cOer1iev9lWhjBeSuvIOjy JLxGp3oYvs0f46hZjbGrEqjSkDQ449FB1N7maOT5PEmcfR6CsI+9G8jxi42z96KjHVy+ wP8yxzDWbLNltoUw0zsUhwA6Bdin9fpXrzsscpSFtGjQ28hGXUKElYGfV/w7MtOW69yV 6F/7c2yOAn7O9f3obVC3lqcsg1259wxuq/YTWmhCMxMnSf/NTx9tR6fOMwCaeWQar8sx kyTQ==
X-Gm-Message-State: ALoCoQlNwAEoAshDli6GPZZfFM0V/oj7rjM1yjbZS0N+JB13m8FLoB0mQnEoTpWXEabJd+g/Qz2N
MIME-Version: 1.0
X-Received: by 10.60.44.243 with SMTP id h19mr5369441oem.46.1400093904486; Wed, 14 May 2014 11:58:24 -0700 (PDT)
Received: by 10.60.60.100 with HTTP; Wed, 14 May 2014 11:58:24 -0700 (PDT)
In-Reply-To: <5373A467.1090903@andrew.cmu.edu>
References: <65E7C5BB55ADC0591730D83C@caldav.corp.apple.com> <5373A467.1090903@andrew.cmu.edu>
Date: Wed, 14 May 2014 19:58:24 +0100
Message-ID: <CAKHUCzw93PMnvTtrcKnW=5YkcC9SNuhOh+3vadLxviOaN9z36w@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Ken Murchison <murch@andrew.cmu.edu>
Content-Type: multipart/alternative; boundary=001a11331cb0d4554504f960c30e
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/iXgXClRUQVZeZgNPp8tcLpxgNvo
Cc: "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] RFC 5524 - what is the proper capability to use?
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 18:58:45 -0000

--001a11331cb0d4554504f960c30e
Content-Type: text/plain; charset=UTF-8

On 14 May 2014 18:14, Ken Murchison <murch@andrew.cmu.edu> wrote:

> On 05/14/2014 12:08 PM, Cyrus Daboo wrote:
>
>> Hi,
>> Whilst researching the issue with missing capabilities in the IANA
>> registry I ran into the following: RFC 5524 (Extended URLFETCH for Binary
>> and Converted Parts) defines a capability string of "URLAUTH=BINARY" in
>> section 3 and the ABNF in Section 5. However, the IANA section uses
>> "URLFETCH=BINARY", which is what IANA has registered at
>> http://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml
>> .
>>
>> The Dovecot server I use advertises "URLAUTH=BINARY".
>>
>> So which is correct? What do other servers do? What do clients expect?
>>
>>
> Cyrus IMAP also uses "URLAUTH=BINARY".


Polymer (which does have URLAUTH), doesn't support RFC 5524, and I don't
know of any other clients that do.

Dave.

--001a11331cb0d4554504f960c30e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
4 May 2014 18:14, Ken Murchison <span dir=3D"ltr">&lt;<a href=3D"mailto:mur=
ch@andrew.cmu.edu" target=3D"_blank">murch@andrew.cmu.edu</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">On 05/14/2014 12:08 PM, Cyrus Daboo wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
Whilst researching the issue with missing capabilities in the IANA registry=
 I ran into the following: RFC 5524 (Extended URLFETCH for Binary and Conve=
rted Parts) defines a capability string of &quot;URLAUTH=3DBINARY&quot; in =
section 3 and the ABNF in Section 5. However, the IANA section uses &quot;U=
RLFETCH=3DBINARY&quot;, which is what IANA has registered at <a href=3D"htt=
p://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml" tar=
get=3D"_blank">http://www.iana.org/<u></u>assignments/imap-capabilities/<u>=
</u>imap-capabilities.xhtml</a>.<br>

<br>
The Dovecot server I use advertises &quot;URLAUTH=3DBINARY&quot;.<br>
<br>
So which is correct? What do other servers do? What do clients expect?<br>
<br>
</blockquote>
<br></div>
Cyrus IMAP also uses &quot;URLAUTH=3DBINARY&quot;.</blockquote><div><br></d=
iv><div>Polymer (which does have URLAUTH), doesn&#39;t support RFC 5524, an=
d I don&#39;t know of any other clients that do.</div><div><br></div><div>
Dave.</div></div></div></div>

--001a11331cb0d4554504f960c30e--


From nobody Wed May 14 14:00:56 2014
Return-Path: <j.sb@sta.samsung.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB411A0129 for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 14:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 JRjRZ2BJk1rZ for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 14:00:53 -0700 (PDT)
Received: from cuda3.sta.samsung.com (mailedge.sta.samsung.com [63.166.115.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB111A01D5 for <imapext@ietf.org>; Wed, 14 May 2014 14:00:52 -0700 (PDT)
X-ASG-Debug-ID: 1400101245-049321106be4b80001-Ao1j2H
Received: from exHub1.telecom.sna.samsung.com ([105.52.12.248]) by cuda3.sta.samsung.com with ESMTP id kjVjKV5DoeOLD0Bo for <imapext@ietf.org>; Wed, 14 May 2014 16:00:45 -0500 (CDT)
X-Barracuda-Envelope-From: j.sb@sta.samsung.com
X-Barracuda-RBL-Trusted-Forwarder: 105.52.12.248
X-ASG-Whitelist: Client
Received: from EXMB5.telecom.sna.samsung.com ([fe80::5f4:56d9:ea68:f480]) by exHub1.telecom.sna.samsung.com ([fe80::804e:878f:5b5a:db50%16]) with mapi id 14.03.0146.000; Wed, 14 May 2014 16:00:45 -0500
From: Jayantheesh S B <j.sb@sta.samsung.com>
X-Barracuda-BWL-IP: fe80::5f4:56d9:ea68:f480
To: "'imapext@ietf.org'" <imapext@ietf.org>
Thread-Topic: Contacts and Calendar Sync for IMAP Protocol
X-ASG-Orig-Subj: Contacts and Calendar Sync for IMAP Protocol
Thread-Index: Ac9ldKh1YRd0P0cXSE25kEH0fuKWfAEso4wwAWPQCZA=
Date: Wed, 14 May 2014 21:00:44 +0000
Message-ID: <02454F842DD7B449B96715A2AD90C0361A15F399@exMB5.telecom.sna.samsung.com>
References: <02454F842DD7B449B96715A2AD90C0361A14E2A8@exMB5.telecom.sna.samsung.com> <02454F842DD7B449B96715A2AD90C0361A1567FC@exMB5.telecom.sna.samsung.com>
In-Reply-To: <02454F842DD7B449B96715A2AD90C0361A1567FC@exMB5.telecom.sna.samsung.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [105.52.12.197]
Content-Type: multipart/alternative; boundary="_000_02454F842DD7B449B96715A2AD90C0361A15F399exMB5telecomsna_"
MIME-Version: 1.0
X-Barracuda-Connect: UNKNOWN[105.52.12.248]
X-Barracuda-Start-Time: 1400101245
X-Barracuda-URL: http://65.169.250.17:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at sta.samsung.com
X-Barracuda-BRTS-Status: 1
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/u-LTsRg-57F_gDpV9s3269d8JdM
Subject: [imapext] Contacts and Calendar Sync for IMAP Protocol
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 21:00:54 -0000

--_000_02454F842DD7B449B96715A2AD90C0361A15F399exMB5telecomsna_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

IMAP Lemonade provides solution for various problems and defines standards =
for various protocol, which is very useful for mobile environment.

We see lot IMAP extension like IDLE, QRESYNC, CONDSTORE are very useful for=
 the end user, since it consumes less battery usage with less mobile data.

Similarly, we see apart from Email sync, Contacts and Calendar sync also gi=
ves lot of value addition and useful for end user.

Right now we did not see any standard in IMAP for Contacts and Calendar syn=
c. But Gmail does this with their own propriety protocol.

Kindly throw some light on this and suggest if any standard protocol alread=
y available for Contact and Calendar Sync ?

Regards,
Jay

--_000_02454F842DD7B449B96715A2AD90C0361A15F399exMB5telecomsna_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi All,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">IMAP Lemonade provides solution for various problems=
 and defines standards for various protocol, which is very useful for mobil=
e environment.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">We see lot IMAP extension like IDLE, QRESYNC, CONDST=
ORE are very useful for the end user, since it consumes less battery usage =
with less mobile data.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Similarly, we see apart from Email sync, Contacts an=
d Calendar sync also gives lot of value addition and useful for end user. &=
nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Right now we did not see any standard in IMAP for Co=
ntacts and Calendar sync. But Gmail does this with their own propriety prot=
ocol. &nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Kindly throw some light on this and suggest if any s=
tandard protocol already available for Contact and Calendar Sync ?
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Regards,<o:p></o:p></p>
<p class=3D"MsoNormal">Jay<o:p></o:p></p>
</div>
</body>
</html>

--_000_02454F842DD7B449B96715A2AD90C0361A15F399exMB5telecomsna_--


From nobody Wed May 14 14:06:40 2014
Return-Path: <cyrus@daboo.name>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8A41A01E1 for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 14:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 r5crzU8I1jlA for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 14:06:36 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF371A01E6 for <imapext@ietf.org>; Wed, 14 May 2014 14:06:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B9EB266402B3; Wed, 14 May 2014 17:06:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE6pbpTI4dD4; Wed, 14 May 2014 17:06:28 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id B866166402A8; Wed, 14 May 2014 17:06:27 -0400 (EDT)
Date: Wed, 14 May 2014 17:06:26 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Jayantheesh S B <j.sb@sta.samsung.com>, "'imapext@ietf.org'" <imapext@ietf.org>
Message-ID: <91E7E96C79A34EA110278CEC@caldav.corp.apple.com>
In-Reply-To: <02454F842DD7B449B96715A2AD90C0361A15F399@exMB5.telecom.sna.samsung.com>
References: <02454F842DD7B449B96715A2AD90C0361A14E2A8@exMB5.telecom.sna.samsung.com> <02454F842DD7B449B96715A2AD90C0361A1567FC@exMB5.telecom.sna.samsung.com> <02454F842DD7B449B96715A2AD90C0361A15F399@exMB5.telecom.sna.samsung.com>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=426
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/Hj9v3e6Z9TsOofU5MpPUmxSBZbk
Subject: Re: [imapext] Contacts and Calendar Sync for IMAP Protocol
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 21:06:38 -0000

Hi Jayantheesh,

--On May 14, 2014 at 9:00:44 PM +0000 Jayantheesh S B 
<j.sb@sta.samsung.com> wrote:

> Right now we did not see any standard in IMAP for Contacts and Calendar
> sync. But Gmail does this with their own propriety protocol.
>
> Kindly throw some light on this and suggest if any standard protocol
> already available for Contact and Calendar Sync ?

CalDAV and CardDAV: RFC 4791 and RFC 6352.

-- 
Cyrus Daboo


From nobody Wed May 14 14:09:36 2014
Return-Path: <blong@google.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC391A0129 for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 14:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 kqv6ZP8TQPv8 for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 14:09:33 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C17AF1A01AB for <imapext@ietf.org>; Wed, 14 May 2014 14:09:27 -0700 (PDT)
Received: by mail-ig0-f172.google.com with SMTP id uy17so7129006igb.17 for <imapext@ietf.org>; Wed, 14 May 2014 14:09:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n6BGqpYaoVAJIW1qMfgmbptuS1a+LdRV3NbtrYp3LBw=; b=FuApPEh9qJIudSijK171HPi3nXduDgUDX68qSHbuDAV2Z/CuU0Ybeni/6aes5HxLHl MQMbURxY0uXEFuXe6Js53hVHqRvJVaDn5pw18UdS3Llbmv347vnITpv4DyzChPyWG9Gp lnehFqs8BvhH4c4/T72eEXE+LgPbcWkUfndIZr29Sv/5w/+iUS/VvcoUOUYgxymT9vpK Jv7e8Z9BeAEfrXU5/oqrwjDcKBzHRxX96JZkV16rT/mYhoYJP5FRC2kC9HLzXDp7mgQG CIYM6Q7YXObf0GP5o+TKLuo7pgQviGzW96dcANsY2xrFdHT1u4hWK7SWE3y+cVPEJHya 4AlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n6BGqpYaoVAJIW1qMfgmbptuS1a+LdRV3NbtrYp3LBw=; b=L6ko2MmeJZBn7vEbIQFyhEW05Tj7GO+BGp49K/itp4YttX2Np79IKwIRsRXVDRm667 PrinYWxqeQCawM3eqlh649jy/rgu5b0seqpdAvrGGnCbItZ+yo2zmuqZ3Exj+7vMMO8q bUYsRVts9amWPN6uHOV/FlhG3UCiSmlffNGMBEmOZbPf/OZEwu7LuksWAyNqv0eMWdiX XmU+eP4C2Q/n8bJDJAQn2Mwd4YvB4+fJlVazcOyag4WO4HfSn+BA2ZsjGUUhgqeelDu4 bT0vzOznS7c7/1uoAyznFknQeRgHe+6NYiN3O6GWJAh/KBOwMJFg4nYIRRdBsefHliC0 AUoA==
X-Gm-Message-State: ALoCoQmWJQLWJf6KPzK9omhbH3gcNWL7Widi1VkWBx1kmlkOTox9uf0Z1tL2u1GKgMvBNjWxo0Ow
MIME-Version: 1.0
X-Received: by 10.42.40.83 with SMTP id k19mr5801846ice.3.1400101760875; Wed, 14 May 2014 14:09:20 -0700 (PDT)
Received: by 10.64.213.73 with HTTP; Wed, 14 May 2014 14:09:20 -0700 (PDT)
In-Reply-To: <91E7E96C79A34EA110278CEC@caldav.corp.apple.com>
References: <02454F842DD7B449B96715A2AD90C0361A14E2A8@exMB5.telecom.sna.samsung.com> <02454F842DD7B449B96715A2AD90C0361A1567FC@exMB5.telecom.sna.samsung.com> <02454F842DD7B449B96715A2AD90C0361A15F399@exMB5.telecom.sna.samsung.com> <91E7E96C79A34EA110278CEC@caldav.corp.apple.com>
Date: Wed, 14 May 2014 14:09:20 -0700
Message-ID: <CABa8R6saTVeZpm+7_nWFcnatXyBQw+LBZqRkcNFg+6pHFvrFpg@mail.gmail.com>
From: Brandon Long <blong@google.com>
To: Cyrus Daboo <cyrus@daboo.name>
Content-Type: multipart/alternative; boundary=90e6ba1efbf41b689104f9629881
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/14yyLoPXPvRONCU_epAdoSDXP6c
Cc: "imapext@ietf.org" <imapext@ietf.org>, Jayantheesh S B <j.sb@sta.samsung.com>
Subject: Re: [imapext] Contacts and Calendar Sync for IMAP Protocol
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 21:09:34 -0000

--90e6ba1efbf41b689104f9629881
Content-Type: text/plain; charset=UTF-8

On Wed, May 14, 2014 at 2:06 PM, Cyrus Daboo <cyrus@daboo.name> wrote:

> Hi Jayantheesh,
>
>
> --On May 14, 2014 at 9:00:44 PM +0000 Jayantheesh S B <
> j.sb@sta.samsung.com> wrote:
>
>  Right now we did not see any standard in IMAP for Contacts and Calendar
>> sync. But Gmail does this with their own propriety protocol.
>>
>> Kindly throw some light on this and suggest if any standard protocol
>> already available for Contact and Calendar Sync ?
>>
>
> CalDAV and CardDAV: RFC 4791 and RFC 6352.


Both of which are supported by Google:
https://developers.google.com/google-apps/calendar/caldav/v2/guide
https://developers.google.com/google-apps/carddav/

Brandon

--90e6ba1efbf41b689104f9629881
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, May 14, 2014 at 2:06 PM, Cyrus Daboo <span dir=3D"ltr">&lt;=
<a href=3D"mailto:cyrus@daboo.name" target=3D"_blank">cyrus@daboo.name</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Hi Jayantheesh,<div class=3D""><br>
<br>
--On May 14, 2014 at 9:00:44 PM +0000 Jayantheesh S B &lt;<a href=3D"mailto=
:j.sb@sta.samsung.com" target=3D"_blank">j.sb@sta.samsung.com</a>&gt; wrote=
:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
Right now we did not see any standard in IMAP for Contacts and Calendar<br>
sync. But Gmail does this with their own propriety protocol.<br>
<br>
Kindly throw some light on this and suggest if any standard protocol<br>
already available for Contact and Calendar Sync ?<br>
</blockquote>
<br></div>
CalDAV and CardDAV: RFC 4791 and RFC 6352.</blockquote><div><br></div><div>=
Both of which are supported by Google:</div><div><a href=3D"https://develop=
ers.google.com/google-apps/calendar/caldav/v2/guide">https://developers.goo=
gle.com/google-apps/calendar/caldav/v2/guide</a></div>
<div><a href=3D"https://developers.google.com/google-apps/carddav/">https:/=
/developers.google.com/google-apps/carddav/</a></div><div><br></div><div>Br=
andon=C2=A0</div></div><br></div></div>

--90e6ba1efbf41b689104f9629881--


From nobody Wed May 14 15:24:08 2014
Return-Path: <brong@fastmail.fm>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E5B1A0302 for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 15:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 MpbhHsGH_dkG for <imapext@ietfa.amsl.com>; Wed, 14 May 2014 15:24:05 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 933E91A0316 for <imapext@ietf.org>; Wed, 14 May 2014 15:24:04 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B6EF92119C for <imapext@ietf.org>; Wed, 14 May 2014 18:23:51 -0400 (EDT)
Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Wed, 14 May 2014 18:23:52 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= UGpBuyToPUsbIqhQLzF31NE428A=; b=VeZ4y3qTwrERZPfJeHo43FUdStn67Fcg ZTOVTdsFhsDdFslVDEdcwSavgYy4wik/HE4ZaC44mAkgXPyalHewvQ1rfiOkXSzd yLEgjhlWhBkFuel5Rk1DQTPKuRT0VGaKkorHHoEboiViz6rzFxFJjcAQdFPWWXMY VTUpHdX9GB4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=UGpBuyToPUsbIqhQLzF31NE428A=; b=TLa KLm3sx1DeyA4QWiIjmp4FVLE9WX0AHKRKx2G11hXt073aT/F0jEucpmEePCAEMxe Rx8t/2eOAuyBVAu0FP9w1sNrsNatYZJtqqkHBgb0FmsRrXMtcG+r4YcKsw7OpDx9 yhDHdEG1WsF+BfweqGargHiQvHXq/lh//+avVLbU=
Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id CA6FA11D4D6; Wed, 14 May 2014 18:23:51 -0400 (EDT)
Message-Id: <1400106231.15046.117515493.492FEBB6@webmail.messagingengine.com>
X-Sasl-Enc: FdAuwJa1bx8BRlFqLyD03CqHkO6g24ui0flY3cvvq9YU 1400106231
From: Bron Gondwana <brong@fastmail.fm>
To: imapext@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_1400106231150465";  charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-0867fb17
In-Reply-To: <02454F842DD7B449B96715A2AD90C0361A15F399@exMB5.telecom.sna.samsung.com>
References: <02454F842DD7B449B96715A2AD90C0361A14E2A8@exMB5.telecom.sna.samsung.com> <02454F842DD7B449B96715A2AD90C0361A1567FC@exMB5.telecom.sna.samsung.com> <02454F842DD7B449B96715A2AD90C0361A15F399@exMB5.telecom.sna.samsung.com>
Date: Thu, 15 May 2014 08:23:51 +1000
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/B4dSsEi9kPdb9CSLGBysm8wHk_Q
Subject: Re: [imapext] Contacts and Calendar Sync for IMAP Protocol
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 22:24:07 -0000

This is a multi-part message in MIME format.

--_----------=_1400106231150465
Content-Transfer-Encoding: 7bit
Content-Type: text/plain

On Thu, May 15, 2014, at 07:00 AM, Jayantheesh S B wrote:

Hi All,


IMAP Lemonade provides solution for various problems and defines
standards for various protocol, which is very useful for mobile
environment.


We see lot IMAP extension like IDLE, QRESYNC, CONDSTORE are very useful
for the end user, since it consumes less battery usage with less mobile
data.


Similarly, we see apart from Email sync, Contacts and Calendar sync
also gives lot of value addition and useful for end user.


Right now we did not see any standard in IMAP for Contacts and Calendar
sync. But Gmail does this with their own propriety protocol.


Kindly throw some light on this and suggest if any standard protocol
already available for Contact and Calendar Sync ?



We support all those standards (CalDAV, CardDAV, and of course all the
IMAP extensions) at FastMail - but we're also working on extending and
opening the JSON protocol we use to communicate between our web
interface and our servers.



You can read our early drafts at [1]http://jmap.io/



The plan is to build an open protocol which can be used more
efficiently by clients who don't have the connection reliability for
IMAP's state-based connections, and over a single protocol through
proxies, etc.



The downside of course is that it's not standard, and it's not done
yet.



Bron.



--
Bron Gondwana
brong@fastmail.fm

References

1. http://jmap.io/

--_----------=_1400106231150465
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html

<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Thu, May 15, 2014, at 07:00 AM, Jayantheesh S B wrote:<br></d=
iv>
<blockquote type=3D"cite"><div><p style=3D"font-family: &quot;Calibri&quot;=
,&quot;sans-serif&quot;; font-size: 11pt; margin: 0in 0in 0.0001pt;">Hi All=
,<br></p><p style=3D"font-family: &quot;Calibri&quot;,&quot;sans-serif&quot=
;; font-size: 11pt; margin: 0in 0in 0.0001pt;">&nbsp;<br></p><p style=3D"fo=
nt-family: &quot;Calibri&quot;,&quot;sans-serif&quot;; font-size: 11pt; mar=
gin: 0in 0in 0.0001pt;">IMAP Lemonade provides solution for various problem=
s and defines standards for various protocol, which is very useful for mobi=
le environment.<br></p><p style=3D"font-family: &quot;Calibri&quot;,&quot;s=
ans-serif&quot;; font-size: 11pt; margin: 0in 0in 0.0001pt;">&nbsp;<br></p>=
<p style=3D"font-family: &quot;Calibri&quot;,&quot;sans-serif&quot;; font-s=
ize: 11pt; margin: 0in 0in 0.0001pt;">We see lot IMAP extension like IDLE, =
QRESYNC, CONDSTORE are very useful for the end user, since it consumes less=
 battery usage with less mobile data.<br></p><p style=3D"font-family: &quot=
;Calibri&quot;,&quot;sans-serif&quot;; font-size: 11pt; margin: 0in 0in 0.0=
001pt;">&nbsp;<br></p><p style=3D"font-family: &quot;Calibri&quot;,&quot;sa=
ns-serif&quot;; font-size: 11pt; margin: 0in 0in 0.0001pt;">Similarly, we s=
ee apart from Email sync, Contacts and Calendar sync also gives lot of valu=
e addition and useful for end user. &nbsp;<br></p><p style=3D"font-family: =
&quot;Calibri&quot;,&quot;sans-serif&quot;; font-size: 11pt; margin: 0in 0i=
n 0.0001pt;">&nbsp;<br></p><p style=3D"font-family: &quot;Calibri&quot;,&qu=
ot;sans-serif&quot;; font-size: 11pt; margin: 0in 0in 0.0001pt;">Right now =
we did not see any standard in IMAP for Contacts and Calendar sync. But Gma=
il does this with their own propriety protocol. &nbsp;<br></p><p style=3D"f=
ont-family: &quot;Calibri&quot;,&quot;sans-serif&quot;; font-size: 11pt; ma=
rgin: 0in 0in 0.0001pt;">&nbsp;<br></p><p style=3D"font-family: &quot;Calib=
ri&quot;,&quot;sans-serif&quot;; font-size: 11pt; margin: 0in 0in 0.0001pt;=
">Kindly throw some light on this and suggest if any standard protocol alre=
ady available for Contact and Calendar Sync ?<br></p><div defang_dir=3D"" c=
lass=3D"">&nbsp;</div>
</div>
</blockquote><div>&nbsp;</div>
<div>We support all those standards (CalDAV, CardDAV, and of course all the=
 IMAP extensions) at FastMail - but we're also working on extending and ope=
ning the JSON protocol we use to communicate between our web interface and =
our servers.<br></div>
<div>&nbsp;</div>
<div>You can read our early drafts at <a href=3D"http://jmap.io/">http://jm=
ap.io/</a><br></div>
<div>&nbsp;</div>
<div>The plan is to build an open protocol which can be used more efficient=
ly by clients who don't have the connection reliability for IMAP's state-ba=
sed connections, and over a single protocol through proxies, etc.<br></div>
<div>&nbsp;</div>
<div>The downside of course is that it's not standard, and it's not done ye=
t.<br></div>
<div>&nbsp;</div>
<div>Bron.<br></div>
<div>&nbsp;</div>
<div id=3D"sig567075"><div class=3D"signature">--<br></div>
<div class=3D"signature">Bron Gondwana<br></div>
<div class=3D"signature">brong@fastmail.fm<br></div>
<div class=3D"signature">&nbsp;</div>
</div>
</body>
</html>

--_----------=_1400106231150465--


From nobody Fri May 16 19:16:14 2014
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55A1A025C for <imapext@ietfa.amsl.com>; Fri, 16 May 2014 19:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 ShITCi9lNWfL for <imapext@ietfa.amsl.com>; Fri, 16 May 2014 19:16:11 -0700 (PDT)
Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259F51A024F for <imapext@ietf.org>; Fri, 16 May 2014 19:16:11 -0700 (PDT)
Received: by mail-ve0-f176.google.com with SMTP id jz11so4007016veb.7 for <imapext@ietf.org>; Fri, 16 May 2014 19:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=B8GWCjLXEBewpMJ9OKXD4uqg4lvpE0hiwnPziGAAhS8=; b=rtDHXBUc0tDC/RdDXGk6ssl/+U3xMrXDDJyg/XK7zu+XBxwsHTG8ct699Q8eNhEI1j 2EDaiq5oiFT84tt4dpE83BWu6nTYaDP2UsnppZ9jtHG+pwwYukmRWOhR4tEjZ3ELeQ4J Azc+hK1mOCiHCTYKURmJCrioQyF9Lc443eiSsfkwoeLIDfifgeFjuqlfwUWhUPF2/o0w Bgl5N97Z8aDjGhEdyJ5XYqYf3Vql3gMfRKeb1kuptEo8jSOouLbLdXsW23cCLr7jfqvQ PBD89JugXy5TxiY2tVoZzvLphVGFwxyHliNlSbjCRJhV8FzG1kaB4JZ8wp8j9d4rjIbB uakQ==
MIME-Version: 1.0
X-Received: by 10.52.134.202 with SMTP id pm10mr78968vdb.55.1400292963164; Fri, 16 May 2014 19:16:03 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.58.33.199 with HTTP; Fri, 16 May 2014 19:16:03 -0700 (PDT)
In-Reply-To: <590026B7623FC8DCB35018FD@cyrus.local>
References: <5372A643.2030309@rename-it.nl> <590026B7623FC8DCB35018FD@cyrus.local>
Date: Fri, 16 May 2014 22:16:03 -0400
X-Google-Sender-Auth: QirUCkflXZ3koaR1cLUunaDRhmA
Message-ID: <CAC4RtVATEcyhfb=myeWoVUfMZvjEqpzY=qbrboonH_yfzV7--A@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Cyrus Daboo <cyrus@daboo.name>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/RauTySkOXpBEO3knaJL6ETON7Uk
Cc: Stephan Bosch <stephan@rename-it.nl>, "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 May 2014 02:16:12 -0000

>> I just noticed that the IMAP METADATA and METADATA-SERVER capabilities
>> (RFC 5464) are not listed in the IANA IMAP capability registry:
>
> Looks like the capabilities were not explicitly included in the IANA section
> of 5464 - my mistake - sorry. So this is an oversight. Perhaps Barry or Pete
> can request IANA to update the registry.

OK, so here's what we did:
The IESG agreed that this was an oversight, that 5464 serves fine as
the Standards Track reference, and that no further documentation is
needed to make the registration happen.  We approved the appropriate
registry update.  While we were at it, we also asked IANA to add
"AUTH=" with a reference to RFC 3501, which is also missing.  We
should see the updates in the registry soon, once IANA has time to
respond to the request.

The URLAUTH=BINARY vs URLFETCH=BINARY issue is more complicated, and
probably will require a quick documentation update to clear it up once
we're sure what the right fix is.

Barry


From nobody Mon May 19 02:39:23 2014
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7841A032A for <imapext@ietfa.amsl.com>; Mon, 19 May 2014 02:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.049
X-Spam-Level: 
X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 xQBaNnhrOFG6 for <imapext@ietfa.amsl.com>; Mon, 19 May 2014 02:39:20 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF351A01A8 for <imapext@ietf.org>; Mon, 19 May 2014 02:39:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1400492359; d=isode.com; s=selector; i=@isode.com; bh=bwaFl3o8zDF6iEudUUlqIlRXcDfYbWJhRfq2cPhcxj8=; 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=uMwxoG1Zvh3SeWpLQ3ulWccB5K2SeRdJwXSkQgE1D7QN23ZLOZG5MsE7axLqb+lkFQaXHV +GhUy51ckPykSvS8hPthK7YgAN5AcIrtT8kpBkycZHj5TDlsOKNFLFRLX2Ds077+hzmBuq SUd416kx2DETjWP/BDj/ptWCVFJGdbI=;
Received: from [172.16.1.29] (richard.isode.com [62.3.217.249])  by waldorf.isode.com (submission channel) via TCP with ESMTPA  id <U3nRRQBz5caw@waldorf.isode.com>; Mon, 19 May 2014 10:39:18 +0100
Message-ID: <5379D177.2070705@isode.com>
Date: Mon, 19 May 2014 10:40:07 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
To: Stephan Bosch <stephan@rename-it.nl>, imapext@ietf.org
References: <5372A643.2030309@rename-it.nl> <590026B7623FC8DCB35018FD@cyrus.local> <CAC4RtVD7EAXREL5xcamYgyAw-Pk7hjtUQShc6BC0hYG5SA3tHQ@mail.gmail.com> <A7D2874065E64D1C05203FB0@cyrus.local> <CAKHUCzyBQVZRy18GYmF_NUThP1HorqJG2A-GmaorprbWeMJ=5Q@mail.gmail.com> <CALaySJLENYD4pfsWCWa+OmNsCQpAeKr=3yyU7qnmPZ-rhcdeRA@mail.gmail.com> <EEDF5181FD7BE63FAC920108@caldav.corp.apple.com> <53739509.5020304@rename-it.nl>
In-Reply-To: <53739509.5020304@rename-it.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/X55ALK9eY9y8sxPHcDr6NvNcWWc
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 09:39:22 -0000

On 14/05/2014 17:08, Stephan Bosch wrote:
> (ohw, somehow mailing list got dropped from To:)
>
> Cyrus Daboo schreef op 14-5-2014 17:26:
>> OK.
>>
>> I was going to do a quick scan and see if any other capabilities are
>> missing. Here is what I found:
>>
>> AUTH= (3501) Not sure this is needed given it is in the base spec 
>> itself.
>>
>> URLAUTH=BINARY (5524) - actually this is bad. The spec uses
>> "URLAUTH=BINARY" in section 3, but uses "URLFETCH=BINARY" in the IANA
>> section (which is registered). However, the Dovecot server I use has
>> "URLAUTH=BINARY". I do not see any errata for 5524 so this issue needs
>> to be addressed.
>
> Ow. That is quite bad indeed.
>
> We didn't notice that either. Dovecot implementation is based on the 
> ABNF.
>
> I know of at least one other server that supports this capability: 
> Cyrus (http://www.imapwiki.org/Specs).
>
> I quickly grepped the source code and, luckily, it uses 
> "URLAUTH=BINARY" too.
>
> Still, I wonder whether there are others. The list on the imapwiki is 
> far from complete, nor up-to-date.
>
> Isode was involved in writing this RFC, but I don't know whether they 
> actually implemented it for their product. Dave?
No, we haven't implemented this. Although it might become more 
interesting in the future.


From nobody Wed May 21 12:04:36 2014
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF071A01C6 for <imapext@ietfa.amsl.com>; Wed, 21 May 2014 12:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 SgjYBvvM6gVB for <imapext@ietfa.amsl.com>; Wed, 21 May 2014 12:04:35 -0700 (PDT)
Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6201A0135 for <imapext@ietf.org>; Wed, 21 May 2014 12:04:34 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id hq16so3080412vcb.23 for <imapext@ietf.org>; Wed, 21 May 2014 12:04:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+2Oz68Xf50heSEBnQltJq2YzlO9xU3g7VDPk9sO/4oY=; b=C060PJbCPT/RtyuGsPQlUsGK+x41Va7tgQJJw1eLBy9lR61Hzk6MwlZT88E/TF0yXD pFWq1j8yuJkpy9fCy7wetPsGSkGH60vQWpZNVjqhhiQ0rPLu2g5BIlEbBqYI/v/mw0GD LBdvTIk+jnJr8kTXZDxy3jWdf+kcEAXj2nwudQsJslaXHMtzV35P2qFcEhX4s94a/FU9 lOOHhwuYMo8eNtcF8sigPUiVNj6i3IPtzh7oNixMMKLbFrhl/j3VYEiYV0kpkM4nFQCR EFBGyrfxZAyLvajkofmRc8/ZDhE/9Zdx1MMW4fBC/u1wfByjqRF6iHRO/db6iU0BlCS5 eGcA==
MIME-Version: 1.0
X-Received: by 10.52.238.161 with SMTP id vl1mr668vdc.88.1400699073350; Wed, 21 May 2014 12:04:33 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.58.33.199 with HTTP; Wed, 21 May 2014 12:04:33 -0700 (PDT)
In-Reply-To: <CAC4RtVATEcyhfb=myeWoVUfMZvjEqpzY=qbrboonH_yfzV7--A@mail.gmail.com>
References: <5372A643.2030309@rename-it.nl> <590026B7623FC8DCB35018FD@cyrus.local> <CAC4RtVATEcyhfb=myeWoVUfMZvjEqpzY=qbrboonH_yfzV7--A@mail.gmail.com>
Date: Wed, 21 May 2014 15:04:33 -0400
X-Google-Sender-Auth: UUNsWEAQ6gonlE3YZwkhhzRS6pQ
Message-ID: <CAC4RtVBG6GyJ=56L0jG3QhyEZFZJ28mQ7uB4Kh_73Bw7xa50jw@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Cyrus Daboo <cyrus@daboo.name>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/uEOwQeGA3MjYyPPbV0EbPeW4kmM
Cc: Stephan Bosch <stephan@rename-it.nl>, "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] METADATA and METADATA-SERVER not in IANA IMAP capability registry.
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 19:04:35 -0000

The change has been made in the registry.

Barry

On Fri, May 16, 2014 at 10:16 PM, Barry Leiba <barryleiba@computer.org> wrote:
>>> I just noticed that the IMAP METADATA and METADATA-SERVER capabilities
>>> (RFC 5464) are not listed in the IANA IMAP capability registry:
>>
>> Looks like the capabilities were not explicitly included in the IANA section
>> of 5464 - my mistake - sorry. So this is an oversight. Perhaps Barry or Pete
>> can request IANA to update the registry.
>
> OK, so here's what we did:
> The IESG agreed that this was an oversight, that 5464 serves fine as
> the Standards Track reference, and that no further documentation is
> needed to make the registration happen.  We approved the appropriate
> registry update.  While we were at it, we also asked IANA to add
> "AUTH=" with a reference to RFC 3501, which is also missing.  We
> should see the updates in the registry soon, once IANA has time to
> respond to the request.
>
> The URLAUTH=BINARY vs URLFETCH=BINARY issue is more complicated, and
> probably will require a quick documentation update to clear it up once
> we're sure what the right fix is.
>
> Barry


From nobody Fri May 23 13:00:11 2014
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349E51A001A; Fri, 23 May 2014 13:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.853
X-Spam-Level: 
X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 DeUModsXDAay; Fri, 23 May 2014 13:00:03 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 73A481A0018; Fri, 23 May 2014 13:00:03 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id C2D7118000D; Fri, 23 May 2014 12:59:42 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20140523195942.C2D7118000D@rfc-editor.org>
Date: Fri, 23 May 2014 12:59:42 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/ze863fwJQ22oPz5yuHVP11l09yo
Cc: drafts-update-ref@iana.org, imapext@ietf.org, rfc-editor@rfc-editor.org
Subject: [imapext] RFC 7162 on IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 20:00:05 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7162

        Title:      IMAP Extensions: Quick Flag Changes 
                    Resynchronization (CONDSTORE) and 
                    Quick Mailbox Resynchronization (QRESYNC) 
        Author:     A. Melnikov, D. Cridland
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2014
        Mailbox:    Alexey.Melnikov@isode.com, 
                    dave.cridland@surevine.com
        Pages:      52
        Characters: 111930
        Obsoletes:  RFC 4551, RFC 5162
        Updates:    RFC 2683

        I-D Tag:    draft-ietf-qresync-rfc5162bis-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7162.txt

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox.  Examples include different clients working on
behalf of the same user and multiple users accessing shared
mailboxes.  These clients need a mechanism to efficiently synchronize
state changes for messages within the mailbox.

Initially defined in RFC 4551, the Conditional Store facility
provides a protected update mechanism for message state information
and a mechanism for requesting only changes to the message state.
This memo updates that mechanism and obsoletes RFC 4551, based on
operational experience.

This document additionally updates another IMAP extension, Quick
Resynchronization, which builds on the Conditional STORE extension to
provide an IMAP client the ability to fully resynchronize a mailbox
as part of the SELECT/EXAMINE command, without the need for
additional server-side state or client round trips.  Hence, this memo
obsoletes RFC 5162.

Finally, this document also updates the line-length recommendation in
Section 3.2.1.5 of RFC 2683.

This document is a product of the IMAP QRESYNC Extension Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


From nobody Mon May 26 07:55:17 2014
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395031A0180 for <imapext@ietfa.amsl.com>; Mon, 26 May 2014 07:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 eI6p3npWCzv8 for <imapext@ietfa.amsl.com>; Mon, 26 May 2014 07:55:13 -0700 (PDT)
Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0181A017E for <imapext@ietf.org>; Mon, 26 May 2014 07:55:13 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hq11so3460305vcb.8 for <imapext@ietf.org>; Mon, 26 May 2014 07:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=gnyBcGpoQJb2DPMyg4QB2waD1h0yiILlEX2n6ctkmPA=; b=yP47VJTruk+GKEQxxCoT4dkQen3SBdjVrLuFuihJUk980x8ApMBHq0cvM39/0Z2LmZ 7+mHg176sfsMPbp4himmWbRTgxhEESZt67GS1lN/TiRlZNheW67V5kOBPuoQefu8taG7 ay0eMrz55BNwplKMlhKg1t3y7lZxi5Fq6SFDoljrkyTgjINVe/MDpVOlPjBRnEMv3mcI rtWq58AJ38Rv9gFgVQj+0eF++ln3dPe/4t1bgVwbbM9oQYEGOCnH8a51R83TBOF2mTaw Wkql7eh21yiKTztB+xr/lR33jX0YeE2uTOE55by6ClEEMaB7x9AsIS/zk/x7Pq616qg0 +D/A==
MIME-Version: 1.0
X-Received: by 10.52.72.4 with SMTP id z4mr1033518vdu.71.1401116109896; Mon, 26 May 2014 07:55:09 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.58.33.199 with HTTP; Mon, 26 May 2014 07:55:09 -0700 (PDT)
In-Reply-To: <20140523195942.C2D7118000D@rfc-editor.org>
References: <20140523195942.C2D7118000D@rfc-editor.org>
Date: Mon, 26 May 2014 10:55:09 -0400
X-Google-Sender-Auth: OtmbmAq8Ybk6-qG0yo7G7KgCc6k
Message-ID: <CAC4RtVDos3aSko4qsngq_L+R6ToCmguyKssWoGqgikv37o7Fsg@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "imapext@ietf.org" <imapext@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/ciAX-kBvF1PSM57Eg6PZ-ak8AaM
Subject: Re: [imapext] RFC 7162 on IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 14:55:14 -0000

> A new Request for Comments is now available in online RFC libraries.
>
>         RFC 7162
>
>         Title:      IMAP Extensions: Quick Flag Changes
>                     Resynchronization (CONDSTORE) and
>                     Quick Mailbox Resynchronization (QRESYNC)
>         Author:     A. Melnikov, D. Cridland

And with the publication of RFC 7162, I will ask the Secretariat to
close the qresync working group.  Thanks to all for the participation,
and thanks to Dave Cridland, Eliot Lear, and Alexey Melnikov for being
chairs and authors.

Barry, Applications AD


From nobody Tue May 27 10:32:28 2014
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD641A01D5; Tue, 27 May 2014 10:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 B8hiif0pq2kx; Tue, 27 May 2014 10:32:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7E1A01AF; Tue, 27 May 2014 10:32:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary <iesg-secretary@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.2.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140527173225.29946.61774.idtracker@ietfa.amsl.com>
Date: Tue, 27 May 2014 10:32:25 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/imapext/AuVB2LrqfCSPhamN4RF-JRUUHOw
Cc: imapext@ietf.org, lear@cisco.com, dave@cridland.net
Subject: [imapext] WG Action: Conclusion of IMAP QRESYNC Extension (qresync)
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: iesg@ietf.org
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 May 2014 17:32:26 -0000

The IMAP QRESYNC Extension (qresync) working group in the Applications 
Area has concluded. The IESG contact persons are Barry Leiba and Pete 
Resnick.

With the publication of RFC 7162, the qrecync working group has
completed its work and will be closed. I thank Dave Cridland and
Eliot Lear for chairing, Alexey Melnikov for editing the updated
document, and all participants for their work on the update.

As always, the <imapext@ietf.org> mailing list will remain open for
further discussion of IMAP extensions.

Barry Leiba, Applications AD