Jayantheesh S B | 5 Jan 18:50 2015

Re: The IMAP APPENDLIMIT Extension

Hi Pete,

Thanks for your review comments. 

Please find my comments inline. 

Regards,
Jay

-----Original Message-----
From: Pete Maclean [mailto:groups <at> maclean.com] 
Sent: Saturday, January 03, 2015 8:11 AM
To: Jayantheesh S B; 'imapext <at> ietf.org'
Subject: Re: [imapext] The IMAP APPENDLIMIT Extension

Jay,

I have not said anything on APPENDLIMIT before but, reading your latest draft now, there are a few things I
wonder about.  I don't think any of these necessarily requires any changes to the draft but some may merit
additional consideration.

In section 5 you make reference to "the server's fixed maximum mail upload size".  What is the intended scope
of said fixedness.  Should a client assume that a maximum upload size obtained in one session applies in a
later session?  I think it should not.  Hardware or other changes at the server could surely lead to a maximum
upload size changing over time.

[Jay] Upload size obtained using SELECT/EXAMINE always overrides the CAPABILITY response. So, maximum
upload size obtained in one session does not apply for another session.

How should a client behave if it obtains a maximum upload size for a given mailbox in a LIST command and then
(Continue reading)

Alexey Melnikov | 4 Jan 19:17 2015

Re: The IMAP APPENDLIMIT Extension

Hi Pete,

On 03/01/2015 13:11, Pete Maclean wrote:
> Jay,
>
> I have not said anything on APPENDLIMIT before but, reading your 
> latest draft now, there are a few things I wonder about.  I don't 
> think any of these necessarily requires any changes to the draft but 
> some may merit additional consideration.
>
> In section 5 you make reference to "the server's fixed maximum mail 
> upload size".  What is the intended scope of said fixedness. Should a 
> client assume that a maximum upload size obtained in one session 
> applies in a later session?  I think it should not.
I don't think this matters, because the limit would be always advertised 
in CAPABILITY response and/or on SELECT anyway.
> Hardware or other changes at the server could surely lead to a maximum 
> upload size changing over time.
>
> How should a client behave if it obtains a maximum upload size for a 
> given mailbox in a LIST command and then later in the same session it 
> does a SELECT/EXAMINE for the same mailbox that quotes a different 
> maximum upload size?  For that matter, is it valid for a server to 
> return different maximum upload sizes in CAPABILITY responses within a 
> single session?  In cases where a maximum upload size is dependent on 
> a quota, it could make sense for these things to happen.
Yes, it is probably sensible to allow for that.
> Surely it would be very valuable to include in this extension a means 
> for a server to indicate that it does not accept APPENDs at all.
APPENDLIMIT=0?
(Continue reading)

Pete Maclean | 3 Jan 14:11 2015

Re: The IMAP APPENDLIMIT Extension

Jay,

I have not said anything on APPENDLIMIT before but, reading your 
latest draft now, there are a few things I wonder about.  I don't 
think any of these necessarily requires any changes to the draft but 
some may merit additional consideration.

In section 5 you make reference to "the server's fixed maximum mail 
upload size".  What is the intended scope of said fixedness.  Should 
a client assume that a maximum upload size obtained in one session 
applies in a later session?  I think it should not.  Hardware or 
other changes at the server could surely lead to a maximum upload 
size changing over time.

How should a client behave if it obtains a maximum upload size for a 
given mailbox in a LIST command and then later in the same session it 
does a SELECT/EXAMINE for the same mailbox that quotes a different 
maximum upload size?  For that matter, is it valid for a server to 
return different maximum upload sizes in CAPABILITY responses within 
a single session?  In cases where a maximum upload size is dependent 
on a quota, it could make sense for these things to happen.

Surely it would be very valuable to include in this extension a means 
for a server to indicate that it does not accept APPENDs at all.  For 
IMAP servers fronting email archives, it is entirely reasonable for 
APPENDs to be unsupported.  In other cases, it seems reasonable for 
APPENDs to be disallowed for certain mailboxes (as, for example, in a 
proxy situation or when a mailbox reaches maximum capacity).  An easy 
way to deal with this would perhaps be to change the syntax to allow 
an append limit of 0 with the meaning, not that zero-length messages 
(Continue reading)

Jayantheesh S B | 19 Dec 23:12 2014

The IMAP APPENDLIMIT Extension

Hi All,

 

Please find the next version of the draft attached with all the review comments addressed.

 

If you have any comments/suggestions in the attached version, kindly share it.

 

Regards,

Jay

INTERNET-DRAFT                                           Jayantheesh S B 
Intended status: Standards Track                                 Samsung
Expires: June 2015                                  Narendra Singh Bisht
                                                                 Samsung
                                                       December 19, 2014

                      The IMAP APPENDLIMIT Extension
                draft-jayantheesh-imap-appendlimit-extension-02

Abstract

This memo defines an extension to the IMAP service whereby a server can
advertise its capability, to support maximum mail upload size using
CAPABILITY, SELECT/EXAMINE and LIST command.

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, and
derivative works of it may not be created, except to publish it as an
RFC and to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This Internet-Draft will expire on June, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.

Jayantheesh & Narendra       Expires June, 2015               [Page 1]

Internet-Draft               IMAP APPENDLIMIT            December 2014

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1. Conventions and Terminology . . . . . . . . . .  . . . . .   2
   2. APPENDLIMIT Extension . . . . . . . . . . . . . . . . . . . . .  2
   3. Mailbox specific APPENDLIMIT . . . . . . . . . . . . . . . . . . 3
     3.1. SELECT response . . . . . . . . . . . . . . . . . . . . . .  4
     3.2. LIST response . . . . . . . . . . . . . . . . . . . . . . .  4
   4. APPEND response . . . . . . . . . . . . . . . . . . . . . . . .  5
   5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
    8.1 Normative References . . . . . . . . . . . . . . . . . . . . . 6
    8.2 Informative References . . . . . . . . . . . . . . . . . . . . 7
   9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . .  7
   10. Author's Address . .. . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

Several IMAP server have limitation for mail upload size which is not
published to the email client.  When email client APPEND a mail with
huge attachments, it fails due to size restriction set by the IMAP
server.  This results in unnecessary resource usage.  Especially in the 
mobile device environment, appending mail with huge attachment consumes
device resources like device battery power and mobile data.

The IMAP APPENDLIMIT extension provides an ability to advertise maximum
upload size allowed by the IMAP server, so that email client knows the
size limitation beforehand.

1.1. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.

Example lines prefaced by "C:" are sent by the client and ones prefaced
by "S:" by the server.  The five characters [...] means that something
has been elided.

2. APPENDLIMIT Extension

An IMAP server that supports APPENDLIMIT advertises this by including
the word APPENDLIMIT in its capability list.  IMAP server shall publish
the supported mail upload size as part of CAPABILITY response.  The

Jayantheesh & Narendra       Expires June, 2015              [Page 2]

Internet-Draft               IMAP APPENDLIMIT           December 2014

advertised upload limit is common across the mailboxes, but client
can still issue SELECT/EXAMINE or LIST command to get the mailbox
specific upload limit set by the IMAP server.  In this case,
APPENDLIMIT value obtained as part of SELECT/EXAMINE or LIST command
takes precedence over the value returned as part of CAPABILITY
response.

The following example, demonstrates the APPENDLIMIT capability with
mailbox limit.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
S: t1 OK foo

If APPENDLIMIT value is omitted in CAPABILITY response, then client
SHOULD issue SELECT/EXAMINE or LIST command to get the mailbox specific
limit set by the server.  New response code APPENDLIMIT is added to get
the mailbox specific limit.  Refer section 5 for response code syntax.

The following example demonstrates, its usage.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT
S: t1 OK foo

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: t2 OK [READ-WRITE] SELECT completed

By looking at the upload size restriction set by the IMAP server, client
MUST not try to upload mail more than advertised limit in the APPEND
command. 

3. Mailbox specific APPENDLIMIT

IMAP server can still have mailbox specific APPENDLIMIT restriction,
which may not be advertised as part of CAPABILITY response.  In this
case, client can issue SELECT/EXAMINE command to get the per mailbox
specific limit set by the server.  Similarly, if client wish to know
the mailbox specific limit in authenticated state, can be done by
issuing the LIST command in combination with STATUS command.

Jayantheesh & Narendra       Expires June, 2015              [Page 3]

Internet-Draft               IMAP APPENDLIMIT           December 2014

3.1 SELECT response

Client can get the per mailbox append limit by issuing the SELECT/
EXAMINE command.  APPENDLIMIT size to this mailbox is obtained as part
of untagged OK response.  In this case, this APPENDLIMIT value will
supersede the value received as part of CAPABILITY response.  If no
per-mailbox APPENDLIMIT is specified for a folder, but the server did
specify a common APPENDLIMIT in the CAPABILITY response, then the
common APPENDLIMIT applies to that folder.

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: [...]
S: t2 OK [READ-WRITE] SELECT completed

In the above example, APPENDLIMIT represents the maximum upload size for
this mailbox.

OK [APPENDLIMIT <n>] Maximum upload limit for this mailbox, in bytes.
                     Refer to section 5 for more information.  If this
                     is missing, the client can always honour the
                     value received as part of CAPABILITY response.

3.2 LIST response

IMAP client can get the mailbox specific APPENDLIMIT in authenticated
state, where it do not need to issue SELECT/EXAMINE command.  LIST
command in combination with STATUS command can be issued to get the per
mailbox specific APPENDLIMIT set by the server.  Refer RFC 5819 for the
usage of LIST command in combination with STATUS command.  Note that a
server implementing this extension, is syntactically compatible with
RFC 5819, however support for RFC 5258 or RFC 5819 is not required,
when implementing this extension.

The following example demonstrates, its usage.

C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT))
S: * LIST () "."  "INBOX"
S: * STATUS "INBOX" (APPENDLIMIT 257890)
S: t1 OK List completed.

New attribute APPENDLIMIT is added to get the limit set by the server
for this mailbox as part of STATUS command.  The STATUS response occurs
as a result of an STATUS command.  It returns the mailbox name that

Jayantheesh & Narendra       Expires June, 2015              [Page 4]

Internet-Draft               IMAP APPENDLIMIT           December 2014

matches the STATUS specification and the requested mailbox status
information.  IMAP server should recognize an extra "RETURN (STATUS
 (APPENDLIMIT))" at the end of a LIST command and emit an extra STATUS
response for each matching mailbox.  Refer to section 5 for the syntax.

Invoking STATUS command with APPENDLIMIT is also acceptable.  Below
example demonstrates, its usage.

C: t1 STATUS INBOX (APPENDLIMIT)
S: * STATUS INBOX (APPENDLIMIT 257890)
S: t1 OK STATUS completed

4. APPEND response

If client uploads a mail which exceeds the maximum upload size set
to that mailbox, then server SHALL reject the APPEND command with a
tagged TOOBIG response code.  Refer RFC 4469 Section (4) for various
APPEND response codes and its handling.

Client can avoid use of LITERAL+, when maximum upload size
supported by the IMAP server is unknown. 

5. Formal syntax

The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234] including the core
rules in Appendix B.1.  [RFC3501] defines the non-terminals
"capability", "resp-text-code" and "status-att".
Except as noted otherwise, all alphabetic characters are case-
insensitive.  The use of upper or lower case characters to define
token strings is for editorial clarity only.  Implementations MUST
accept these strings in a case-insensitive fashion.

appendlimit-cap = "APPENDLIMIT" ["=" nz-number]
capability /= appendlimit-cap

appendlimit-respcode = "APPENDLIMIT" SP nz-number
resp-text-code /= appendlimit-respcode

appendlimit-status-att = "APPENDLIMIT"
status-att /=appendlimit-status-att

A non-zero number indicating the fixed maximum message size in bytes
that the server will accept.  The syntax of the parameter follows the
augmented BNF notation of [RFC5234].  If this capability is
omitted, no information is conveyed about the server's fixed maximum
mail upload size.

Jayantheesh & Narendra       Expires June, 2015              [Page 5]

Internet-Draft               IMAP APPENDLIMIT           December 2014

6. Security Consideration

It is believed that this extension doesn't add any new security
considerations that are not already present in the base IMAP
protocol [RFC3501].

7. IANA Considerations

The IANA is requested to add APPENDLIMIT to the IMAP4 Capabilities
Registry.  [[Note to RFC-editor: please remove the following before
publication: This registration should take place at the following
location: http://www.iana.org/assignments/imap4-capabilities]]

8. References

8.1 Normative References

The following documents contain definitions or specifications that
are necessary to understand this document properly

[RFC2119]  Bradner, "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, Harvard University, March
           1997.

[RFC3501]  Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
           University of Washington, March 2003

[RFC5234]  Crocker, Overell, "Augmented BNF for Syntax
           Specifications: ABNF", RFC 5234, Brandenburg
           Internetworking, Demon Internet Ltd, January 2008

[RFC5322]  P. Resnick, Ed, "Internet Message Format", RFC 5322,
           Qualcomm Incorporated, October 2008

[RFC2088]  J. Myers, Carnegie Mellon, "IMAP4 non-synchronizing
           literals",  January 1997
		   
[RFC4469]  P. Resnick, "Internet Message Access Protocol (IMAP)
           CATENATE Extension",  April 2006
		   
[RFC5819]  A. Melnikov, T. Sirainen, "IMAP4 Extension for Returning
           STATUS Information in Extended LIST",  March 2010
		   
[RFC5258]  A. Melnikov, B. Leiba, "Internet Message Access Protocol
           version 4 - LIST Command Extensions",  March 2010

		   
Jayantheesh & Narendra       Expires June, 2015               [Page 6]

Internet-Draft               IMAP APPENDLIMIT           December 2014
		   
8. 2 Informative References

The following documents describe related protocols:

[RFC2087]  Myers, J., "IMAP4 QUOTA extension", RFC 2087,
           January 1997

[RFC7377]  B. Leiba, A. Melnikov, "IMAP4 Multimailbox SEARCH
           Extension", RFC 7377, October 2014

9. Acknowledgement

TBD

10. Author's Address

Jayantheesh S B
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: jayantheesh.sb <at> gmail.com

Narendra Singh Bisht
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: narendrasingh.bisht <at> gmail.com

	
	
	
	

	
	
	
	
	
	
Jayantheesh & Narendra       Expires May, 2015               [Page 6]
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Thomas Dreßler | 19 Dec 10:20 2014
Picon

Re: imapext Digest, Vol 29, Issue 17

hi,

what is the meaning of th capability responses?

(1a) one limit for all folders

a client receive an capability response with "global" appendlimit.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890 LIST-EXTENDED LIST-STATUS
S: t1 OK foo

are "a LIST "" % RETURN (STATUS (APPENDLIMIT))" or "a STATUS (APPENDLIMIT)" valid command's for the client?
must an server implement it? must an server reply APPENDLIMIT in SELECT/EXAMINE?
is it allowed for an server to return other APPENDLIMIT's in later SELECT/LIST/STATUS commands? if yes
change this the global limit, or overwrite it the local limit?

(1b)

a client receive an capability response with "local" append-limit (no LIST-STATUS capability).

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT
S: t1 OK foo

is "a LIST "" % RETURN (STATUS (APPENDLIMIT))" realy an valid command, also if the server don't support extended list?
must an server return APPENDLIMIT on every SELECT/EXAMINE command? also on read-only folders? is an APPENDLIMIT other than zero on EXAMINE not an false idea?

example:
A932 EXAMINE blurdybloop S: * 17 EXISTS S: * 2 RECENT S: * OK [UNSEEN 8] Message 8 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS ()] No permanent flags permitted S: * OK [APPENDLIMIT 0] Maximum upload limit S: A932 OK [READ-ONLY] EXAMINE completed Regards,
ThomasD









On 17.12.2014 13:01, imapext-request <at> ietf.org wrote:
Send imapext mailing list submissions to imapext <at> ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/imapext or, via email, send a message with subject or body 'help' to imapext-request <at> ietf.org You can reach the person managing the list at imapext-owner <at> ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of imapext digest..."

Today's Topics: 1. Re: [IMAP] APPEND Command Usage (Jayantheesh S B) 2. Re: [IMAP] APPEND Command Usage (Michael M Slusarz)

_______________________________________________ imapext mailing list imapext <at> ietf.org https://www.ietf.org/mailman/listinfo/imapext


-- Thomas Dreßler Software-Entwickler Mail System Development 1&1 Internet AG | Brauerstraße 48 | 76135 Karlsruhe | Germany Phone: +49 721 91374-6790 E-Mail: thomas.dressler <at> 1und1.de | Web: www.1und1.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 6484 Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, Christian Würst Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
narendra singh bisht | 17 Dec 22:31 2014
Picon

Deleting Gmail Starred mail.

Hey Folks,

I am seeing the below behavior in case of Gmail Drafts mail.

Anyone know if it is an intended behavior?

 

I have a Drafts mail with subject M1.

M1 is starred.

When I edit M1 and change subject to M2 from client (mobile device), what I do is APPEND the new M2 and set the /DELETE flag for M1.

But on the Gmail web client, I can still see the M1 intact in Drafts mailbox, I also see M2.

 

Can’t we delete starred mail by setting /DELETE flag?


Thanks in advance

--
Thanks & Regards
-Narendra
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jamie Nicolson (倪志明 | 5 Dec 23:02 2014
Picon

client support for RFC 3516 (BINARY)?

Anyone know of clients that support RFC 3516? It seems like it could be particularly useful for mobile clients, to reduce both download size and CPU usage for base64-decoding.
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Timo Sirainen | 2 Dec 07:39 2014
Picon
Picon

Fetching short text snippet for mails

Nowadays many mail clients want to show about 100 chars of the beginning of mail, so there should be a nice and
efficient way for clients to request this. I'm now wondering what would be a nice IMAP way of implementing
this. Does anyone have some suggestions? There's what I've come up with so far:

a) FETCH n (SNIPPET)
 - Would require writing a new RFC (or just use X-SNIPPET for internal use)

b) FETCH n (ANNOTATION (/vendor/vendor.dovecot.snippet))
 - Would require implementing ANNOTATE, which is a lot of work. But it could also be implemented just
minimally for this specific command.
 - Standardizing vendor.dovecot.snippet would probably require new RFC

c) CONVERT n ("text/vnd.dovecot.snippet" ("length" "100")) BINARY[BODY]
 - Would require implementing CONVERT, which is a lot of work. But it could also be implemented just
minimally for this specific command.
 - Standardizing vnd.dovecot.snippet would probably require new RFC

d) CONVERT n ("text/plain") BINARY[BODY]<0.100>
 - CONVERT RFC says it's legal to convert entire multiparts, but doesn't say exactly what should be done with
them. This is probably a valid use case though.
 - Downside to this compared to others is that this always fetches the first 100 chars, while the others could
also be smarter and skip over quoted text and such.

I think I'm leaning towards b)

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Jayantheesh S B | 12 Nov 23:22 2014

Re: [IMAP] International mailbox names

Dear All,

 

Please share your response on this below query.

 

Regards,

Jay

 

From: Jayantheesh S B
Sent: Tuesday, November 11, 2014 6:21 PM
To: 'imapext <at> ietf.org'
Cc: Jayantheesh S B
Subject: [IMAP] International mailbox names

 

Dear All,

 

As per RFC 3501, for international mailbox names, MODIFIED UTF 7 CHARSET format should be used.

 

we see Yahoo IMAP server is not honoring the request with this charset, whereas other ISP like, Gmail, AOL, Isode supports it.  

 

We are not sure how many providers available in the market really honoring this format.

 

Is there any way email client can know, all the charset supported by the IMAP server?  So, that client can ignore the particular charset format with that server.

 

Please find the log snippet below.

 

Yahoo:

---------

>>> 114 CAPABILITY

<<< #null# ["CAPABILITY", "IMAP4rev1", "ID", "NAMESPACE", "X-ID-ACLID", "UIDPLUS", "LITERAL+", "CHILDREN", "XAPPLEPUSHSERVICE", "XYMHIGHESTMODSEQ", "AUTH=PLAIN", "AUTH=LOGIN", "AUTH=OAUTH2", "AUTH=XYMCOOKIE", "AUTH=XYMECOOKIE", "AUTH=XYMCOOKIEB64", "AUTH=XYMPKI"]

 

>>> 77 STATUS "&C4cLqAvNC6QLvwuvC74-" (UIDVALIDITY)

<<< #77# ["NO", ["CANNOT"], "STATUS Mailbox name(s) cannot be encoded using the specified charset"]

 

>>> 79 CREATE "&C4cLqAvNC6QLvwuvC74-"

<<< #79# ["NO", ["CANNOT"], "CREATE Mailbox name(s) cannot be encoded using the specified charset"]

 

action=create newMailboxName=இந்தியா result=failure reason=#79# ["NO", ["CANNOT"], "CREATE Mailbox name(s) cannot be encoded using the specified charset"]

 

 

Gmail:

---------

 

>>> 74 CAPABILITY

<<< #null# ["CAPABILITY", "IMAP4rev1", "UNSELECT", "IDLE", "NAMESPACE", "QUOTA", "ID", "XLIST",  "CHILDREN", "X-GM-EXT-1", "UIDPLUS",  "COMPRESS=DEFLATE", "ENABLE", "MOVE",  "CONDSTORE", "ESEARCH", "UTF8=ACCEPT"]

 

>>> 49 STATUS "&C4cLqAvNC6QLvwuvC74-" (UIDVALIDITY)

<<< #49# ["NO", ["NONEXISTENT"], "Invalid folder: &C4cLqAvNC6QLvwuvC74- (Failure)"]

 

>>> 51 CREATE "&C4cLqAvNC6QLvwuvC74-"

<<< #51# ["OK", "Success"]

 

action=create newMailboxName=இந்தியா result=success

 

Regards,

Jay

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 12 Nov 00:21 2014

[IMAP] International mailbox names

Dear All,

 

As per RFC 3501, for international mailbox names, MODIFIED UTF 7 CHARSET format should be used.

 

we see Yahoo IMAP server is not honoring the request with this charset, whereas other ISP like, Gmail, AOL, Isode supports it.  

 

We are not sure how many providers available in the market really honoring this format.

 

Is there any way email client can know, all the charset supported by the IMAP server?  So, that client can ignore the particular charset format with that server.

 

Please find the log snippet below.

 

Yahoo:

---------

>>> 114 CAPABILITY

<<< #null# ["CAPABILITY", "IMAP4rev1", "ID", "NAMESPACE", "X-ID-ACLID", "UIDPLUS", "LITERAL+", "CHILDREN", "XAPPLEPUSHSERVICE", "XYMHIGHESTMODSEQ", "AUTH=PLAIN", "AUTH=LOGIN", "AUTH=OAUTH2", "AUTH=XYMCOOKIE", "AUTH=XYMECOOKIE", "AUTH=XYMCOOKIEB64", "AUTH=XYMPKI"]

 

>>> 77 STATUS "&C4cLqAvNC6QLvwuvC74-" (UIDVALIDITY)

<<< #77# ["NO", ["CANNOT"], "STATUS Mailbox name(s) cannot be encoded using the specified charset"]

 

>>> 79 CREATE "&C4cLqAvNC6QLvwuvC74-"

<<< #79# ["NO", ["CANNOT"], "CREATE Mailbox name(s) cannot be encoded using the specified charset"]

 

action=create newMailboxName=இந்தியா result=failure reason=#79# ["NO", ["CANNOT"], "CREATE Mailbox name(s) cannot be encoded using the specified charset"]

 

 

Gmail:

---------

 

>>> 74 CAPABILITY

<<< #null# ["CAPABILITY", "IMAP4rev1", "UNSELECT", "IDLE", "NAMESPACE", "QUOTA", "ID", "XLIST",  "CHILDREN", "X-GM-EXT-1", "UIDPLUS",  "COMPRESS=DEFLATE", "ENABLE", "MOVE",  "CONDSTORE", "ESEARCH", "UTF8=ACCEPT"]

 

>>> 49 STATUS "&C4cLqAvNC6QLvwuvC74-" (UIDVALIDITY)

<<< #49# ["NO", ["NONEXISTENT"], "Invalid folder: &C4cLqAvNC6QLvwuvC74- (Failure)"]

 

>>> 51 CREATE "&C4cLqAvNC6QLvwuvC74-"

<<< #51# ["OK", "Success"]

 

action=create newMailboxName=இந்தியா result=success

 

Regards,

Jay

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 6 Nov 21:40 2014

Re: [IMAP] APPEND Command Usage

Hi All,

Please find the updated version of the Draft attached.

I have addressed the review comments related to ABNF and updated RFC reference section. 

Regards,
Jay
-----Original Message-----
From: Jayantheesh S B 
Sent: Saturday, November 01, 2014 11:26 PM
To: 'Jan Kundrát'; 'imapext <at> ietf.org'
Subject: RE: [imapext] [IMAP] APPEND Command Usage

Hi Jan,

Please find my response inline. 

Regards,
Jay
-----Original Message-----
From: Jan Kundrát [mailto:jkt <at> flaska.net]
Sent: Friday, October 31, 2014 9:08 PM
To: imapext <at> ietf.org
Subject: Re: [imapext] [IMAP] APPEND Command Usage

On Saturday, 1 November 2014 01:37:15 CEST, Jayantheesh S B wrote:
> I have created a short document “IMAP APPENDLIMIT extension” , which 
> proposes the CAPABILITY based solution for the APPEND command usage 
> issue.

I tend to think that using QUOTA for this would be a bit more intuitive, but CAPABILITY will of cousre work as
well. I don't think there's much real-world need for per-mailbox APPEND size limits.

> capability    =/ "APPENDLIMIT=" size-param
> 
> A decimal number indicating the fixed maximum message size in bytes 
> that the server will accept. The syntax of the parameter is as 
> follows, using the augmented BNF notation of [RFC 822]:
> 
> size-param = [1*DIGIT]

You could probably use a nz-number from RFC3501 here. Also, you put the grammar within square brackets
which mean that this is an optional production, and therefore you allow a capability named just
"APPENDLIMIT=". 
Is that what you mean? If so, how should a client interpret that?

[Jay] Thanks for your review comments. This number is not the optional one, hence I will change the grammar
accordingly. 
         As per your comments, I will update the value as well to nz-number. 

With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/



INTERNET-DRAFT                                           Jayantheesh S B 
Intended status: Standards Track                                 Samsung
Expires: May 2015                                   Narendra Singh Bisht
                                                                 Samsung
                                                        November 6, 2014

                      The IMAP APPENDLIMIT Extension
                draft-jayantheesh-imap-appendlimit-extension-01

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, and
derivative works of it may not be created, except to publish it as an
RFC and to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This Internet-Draft will expire on May, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.

Abstract

This memo defines an extension to the IMAP service whereby a server can
advertise its capability, to support maximum mail upload size using
CAPABILITY command.

Jayantheesh & Narendra       Expires May, 2015               [Page 1]

Internet-Draft               IMAP APPENDLIMIT           November 2014

1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.

Example lines prefaced by "C:" are sent by the client and ones prefaced
by "S:" by the server.  The five characters [...] means that something
has been elided.

2. Overview

Several IMAP server have limitation in mail upload size which is not
published to the email client.  When email client APPEND a mail with
huge attachments, it fails due to size restriction set by the IMAP
server.  This results in unnecessary resource usage, especially in the 
mobile device environment, appending mail with huge attachment consumes
device resources like device battery power and mobile data.

The IMAP APPENDLIMIT extension provides an ability to advertise maximum
upload size allowed by the IMAP server, so that email client knows the
size limitation beforehand.

As part of CAPABILITY response, IMAP server should publish the supported
mail upload size.  The following example demonstrates its usage.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
S: t1 OK foo

By looking at the upload size restriction set by the IMAP server, client
SHALL not try to upload mail more than advertised limit in the APPEND
command.

3. Formal syntax

The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234] including the core
rules in Appendix B.1.  [RFC3501] defines the non-terminals
"capability".

Jayantheesh & Narendra       Expires May, 2015               [Page 2]

Internet-Draft               IMAP APPENDLIMIT           November 2014

Except as noted otherwise, all alphabetic characters are case-
insensitive.  The use of upper or lower case characters to define
token strings is for editorial clarity only.  Implementations MUST
accept these strings in a case-insensitive fashion.

capability    =/ "APPENDLIMIT=" nz-number

A non zero number indicating the fixed maximum message size in bytes
that the server will accept.  The syntax of the parameter follows the
augmented BNF notation of [RFC5322, RFC6854].  If the capability is
omitted, no information is conveyed about the server's fixed maximum
message size.

4. Security Consideration

It is believed that this extension doesn't add any new security
considerations that are not already present in the base IMAP
protocol [RFC3501].

5. IANA Considerations

The IANA is requested to add APPENDLIMIT to the IMAP4 Capabilities
Registry.  [[Note to RFC-editor: please remove the following before
publication: This registration should take place at the following
location: http://www.iana.org/assignments/imap4-capabilities]]

6. References

6.1 Normative References

The following documents contain definitions or specifications that
are necessary to understand this document properly

[RFC2119]  Bradner, "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, Harvard University, March
           1997.

[RFC3501]  Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
           University of Washington, March 2003

[RFC5234]  Crocker, Overell, "Augmented BNF for Syntax
           Specifications: ABNF", RFC 5234, Brandenburg
           Internetworking, Demon Internet Ltd, January 2008

[RFC5322]  P. Resnick, Ed, "Internet Message Format", RFC 5322,
           Qualcomm Incorporated, October 2008

[RFC6854]  B. Leiba, "Update to Internet Message Format to Allow
           Group Syntax in the "From:" and "Sender:" Header Fields",
           RFC 6854, Huawei Technologies, March 2013

Jayantheesh & Narendra       Expires May, 2015               [Page 3]

Internet-Draft               IMAP APPENDLIMIT           November 2014

6. 2 Informative References

The following documents describe related protocols:

[RFC2087]  Myers, J., "IMAP4 QUOTA extension", RFC 2087,
           January 1997

7. Acknowledgement

TBD

8. Author's Address

Jayantheesh S B
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: jayantheesh.sb <at> gmail.com

Narendra Singh Bisht
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: narendrasingh.bisht <at> gmail.com

(RFC Editor: Please delete everything after this point)
Changes since -00

    - Updated the latest RFC reference section

    - ABNF grammar updated 

    - Format modified
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Gmane