Nigar Sultana | 29 Aug 04:26 2015
Picon

IMAP BODY STRUCTURE

Hello All,

As per RCS5.3 recommendation the IMAP message archived on server includes MIME content-type Message/CPIM. CPIM wrapped MIME can have attachment content-type=multipart/related.

Eg: 
From: tel:+4917112345678

To: Joe User <joe <at> user.org>, tel:0401234567

Cc: tel:+358501234567

Date: Tue, 27 01 2015 17:57:16 +0100

Subject: This is an example

Message-Context: multimedia-message

Content-Type: Message/CPIM

 

From: tel:+4917112345678

To: Joe User <joe <at> user.org>

To: tel:0401234567

cc: tel:+358501234567

DateTime: 2015-01-27T16:32:55+01:00

Subject: This is an example

NS: imdn <urn:ietf:params:imdn>
NS: rcs <http://www.gsma.org>

imdn.Message-ID: 654131a654131a654131a654131a8994123

imdn.Disposition-Notification: display

rcs.Mms-Message-Class: "Personal"

Content-Type: Multipart/Related;boundary="example-1";start=<950118>; type=application/smil

--example-1

Content-Type: application/smil

Content-ID: <950118>"

 [presentation]

--example-1

Content-Type: text/plain

Content-ID: <950119>

[text]

--example-1

Content-Type: image/jpeg

Content-ID: <950120>

[image]

--example-1--



The question we have is the Body Structure is returning only Message/CPIM body part information and it is not sending sub body structure information. Due to which on client side CPIM message parsing has to be developed. 

Wanted clarification from the group whether it is server issue. Ideally sub body part info server has to pass 

Regards
Nigar Sultana


_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Anita | 28 Aug 22:25 2015
Picon

(no subject)

What is this regarding?
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

S Moonesamy | 19 Aug 16:04 2015

WGLC for draft-ietf-imapapnd-appendlimit-extension-02

Hello,

This message starts a Working Group Last Call for "The IMAP 
APPENDLIMIT Extension" 
(draft-ietf-imapapnd-appendlimit-extension-02).  The I-D can be accessed at
https://tools.ietf.org/html/draft-ietf-imapapnd-appendlimit-extension-02

This Working Group Last Call starts on Wednesday 19th August and will 
end on Thursday 3th September.  Please review the I-D and send 
comments to the imapext <at> ietf.org mailing list.

Regards,
S. Moonesamy (as imapapdb WG Chair)

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

Naren | 12 Aug 21:06 2015
Picon

Re: imapext Digest, Vol 37, Issue 3

We will have this removed from section 3.1, in the next version.

[APPENDLIMIT <n>] Maximum upload limit for this mailbox, in bytes.
                  Refer to section 5 for more information.

On Wed, Aug 12, 2015 at 3:00 PM, <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. I-D Action:       draft-ietf-imapapnd-appendlimit-extension-01.txt
      (internet-drafts <at> ietf.org)
   2. Re: I-D Action:
      draft-ietf-imapapnd-appendlimit-extension-01.txt (Alexey Melnikov)
   3. Re: MULTISEARCH - rfc6237 (Chris Newman)
   4. Re: I-D Action:
      draft-ietf-imapapnd-appendlimit-extension-01.txt (Jamie Nicolson)


---------- Forwarded message ----------
From: internet-drafts <at> ietf.org
To: <i-d-announce <at> ietf.org>
Cc: imapext <at> ietf.org
Date: Wed, 12 Aug 2015 09:16:03 -0700
Subject: [imapext] I-D Action: draft-ietf-imapapnd-appendlimit-extension-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IMAP APPEND Extensions Working Group of the IETF.

        Title           : The IMAP APPENDLIMIT Extension
        Authors         : Jayantheesh SB
                          Narendra Singh Bisht
        Filename        : draft-ietf-imapapnd-appendlimit-extension-01.txt
        Pages           : 7
        Date            : 2015-08-12

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, STATUS and LIST commands.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-imapapnd-appendlimit-extension-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-imapapnd-appendlimit-extension-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/




---------- Forwarded message ----------
From: Alexey Melnikov <alexey.melnikov <at> isode.com>
To: 
Cc: imapext <at> ietf.org
Date: Wed, 12 Aug 2015 17:52:00 +0100
Subject: Re: [imapext] I-D Action: draft-ietf-imapapnd-appendlimit-extension-01.txt
Hi,

On 12/08/2015 17:16, internet-drafts <at> ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the IMAP APPEND Extensions Working Group of the IETF.

         Title           : The IMAP APPENDLIMIT Extension
         Authors         : Jayantheesh SB
                           Narendra Singh Bisht
        Filename        : draft-ietf-imapapnd-appendlimit-extension-01.txt
        Pages           : 7
        Date            : 2015-08-12

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, STATUS and LIST commands.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-imapapnd-appendlimit-extension-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-imapapnd-appendlimit-extension-01
I like changes in this version. One small thing:

In Section 3.1:

[APPENDLIMIT <n>] Maximum upload limit for this mailbox, in bytes.
                  Refer to section 5 for more information.

This is not related to the STATUS command. Have you forgotten to delete these 2 lines?
If not, they need to be moved to a separate section defining a new response code.





---------- Forwarded message ----------
From: Chris Newman <chris.newman <at> oracle.com>
To: Jayantheesh S B <j.sb <at> sta.samsung.com>, imapext <at> ietf.org
Cc: 
Date: Wed, 12 Aug 2015 10:40:48 -0700
Subject: Re: [imapext] MULTISEARCH - rfc6237
--On August 11, 2015 15:20:40 +0000 Jayantheesh S B <j.sb <at> sta.samsung.com>
wrote:
> All,
>
> Is there any server available in the market to validate the
> http://tools.ietf.org/search/rfc6237 extension?

Yes:

http://www.oracle.com/us/products/applications/communications/unified-communications/messaging-server/overview/index.html

version 8.0 and later.

                - Chris




---------- Forwarded message ----------
From: Jamie Nicolson <nicolson <at> google.com>
To: "imapext <at> ietf.org" <imapext <at> ietf.org>
Cc: 
Date: Wed, 12 Aug 2015 11:43:23 -0700
Subject: Re: [imapext] I-D Action: draft-ietf-imapapnd-appendlimit-extension-01.txt
This new draft looks very good, thanks.

On Wed, Aug 12, 2015 at 9:16 AM, <internet-drafts <at> ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IMAP APPEND Extensions Working Group of the IETF.

        Title           : The IMAP APPENDLIMIT Extension
        Authors         : Jayantheesh SB
                          Narendra Singh Bisht
        Filename        : draft-ietf-imapapnd-appendlimit-extension-01.txt
        Pages           : 7
        Date            : 2015-08-12

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, STATUS and LIST commands.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-imapapnd-appendlimit-extension-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-imapapnd-appendlimit-extension-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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




--
Thanks & Regards
-Narendra
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Jayantheesh S B | 11 Aug 17:20 2015

MULTISEARCH - rfc6237

All,

 

Is there any server available in the market to validate the http://tools.ietf.org/search/rfc6237 extension?

 

Regards,

Jay

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Alexey Melnikov | 26 Jul 16:53 2015

Review of draft-ietf-imapapnd-appendlimit-extension-00

Hi,
SM asked me to review the document, so I reread everything for the first
time in a couple of months. Here are my comments:

> 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.

As per the recent discussion, the above text should be amended to make
it clear that both "APPENDLIMIT" and "APPENDLIMIT=<value>" can be
advertised. As traditionally IMAP uses exact match for capabilities,
"APPENDLIMIT=..." is not going to work for a client that looks for exact
match with "APPENDLIMIT".

> The
> 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.

 [snip]

> 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.

I think you should clarify here that a standalone STATUS command can
also be used.

> 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

After Chris Newman's comment that a new SELECT/EXAMINE response code
going to waste lots of bandwidth as most of the time it would be
returned and the client is not going to care, I am wondering again if we
should remove the SELECT response. But I don't have strong feelings on this.

> 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.

It occurred to me that this response code can also be returned in a NO
response on a failed APPEND. It might be worth saying that. (This would
cover a slightly different case from TOOBIG response code.)

> 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.

After the discussion with Jamie I am wondering if we have to require use
of extended LIST with the new APPENDLIMIT STATUS item. Maybe we can just
require implementation of the APPENDLIMIT STATUS item, and
STATUS-in-LIST will take care of this, if also advertised?

> 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" ["=" append-limit-value]
> capability /= appendlimit-cap
> 
> appendlimit-respcode = "APPENDLIMIT" SP append-limit-value
> resp-text-code /= appendlimit-respcode
> 
> append-limit-value = 1*DIGIT
>                      ; Unsigned 64-bit integer
>                      ; (0 <= n < 18,446,744,073,709,551,615)

After thinking more about this, I think we should revert to 32 bit
limits, because if a message is >= 2**32 octets, FETCH RFC822.SIZE would
be unable to return the message size, so other things would break.

So I think we should have a separate extension that takes care of 64bit
message/body part sizes.

Best Regards,
Alexey

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

internet-drafts | 26 Jul 16:23 2015
Picon

I-D Action: draft-ietf-imapapnd-rfc2088bis-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IMAP APPEND Extensions Working Group of the IETF.

        Title           : IMAP4 non-synchronizing literals
        Author          : Alexey Melnikov
	Filename        : draft-ietf-imapapnd-rfc2088bis-00.txt
	Pages           : 7
	Date            : 2015-07-26

Abstract:
   The Internet Message Access Protocol (RFC 3501) contains the
   "literal" syntactic construct for communicating strings.  When
   sending a literal from client to server, IMAP requires the client to
   wait for the server to send a command continuation request between
   sending the octet count and the string data.  This document specifies
   an alternate form of literal which does not require this network
   round trip.

   This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.
   The former allows the alternate form of literals in all IMAP command.
   The latter is the same as LITERAL+, but disallow the alternate form
   in IMAP APPEND, unless they are 4096 bytes or less.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-rfc2088bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-imapapnd-rfc2088bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Jayantheesh S B | 23 Jul 21:05 2015

Re: Review for first draft for draft-ietf-imapapnd-appendlimit-extension

HI Jamie,
 
Thanks for reviewing the document again.
 
Please find my response.
 
Regards,
Jay
---------- Forwarded message ----------
From: Jamie Nicolson <nicolson <at> google.com>
Date: Thu, Jul 23, 2015 at 1:41 PM
Subject: Re: [imapext] Review for first draft for draft-ietf-imapapnd-appendlimit-extension
Cc: "imapext <at> ietf.org" <imapext <at> ietf.org>, "Jayantheesh S.B"
 
 
Thanks Jay. A few comments.
 
Section 3.2: This section seems to imply that the extended list syntax for STATUS APPENDLIMIT must be supported by any server that advertises the APPENDLIMIT capability, regardless of whether it supports LIST-EXTENDED and LIST-STATUS. I think we should clarify that this section will only apply to servers that support LIST-EXTENDED, LIST-STATUS, and APPENDLIMIT. Supporting the new syntax might be non-trivial, and will be wasted work for servers that don't support per-mailbox limits (see below).
 
[Jay] When server does not support the mailbox specific limit, then capability response is enough for the client to know the limit.
 
SELECT and LIST response is needed only when server supports mailbox specific limit. It is not mandatory for the server to implement LIST STATUS, LIST-EXTENDED to get the mailbox specific limit.
 
“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.”
 
Mailbox-specific appendlimits: Our server will have a single appendlimit for all mailboxes, so we don't need the per-mailbox limits. However, the only way for a client to determine this will be to issue a SELECT or extended LIST on the target mailbox and note the absence of a per-mailbox appendlimit response. SELECT is expensive, and not all servers support extended list. Is there a way we could annotate the APPENDLIMIT capability to indicate that per-mailbox limits are not supported, so clients needn't bother querying them? It could be something as simple as adding a magic atom-char like '+' or
'!':
 
APPENDLIMIT=25000000!   ; system-wide append limit is 25000000,
applies to all mailboxes
 
[Jay] In Section 2, its mentioned that, when an IMAP server does not support the mailbox specific limit (Google server case), then as part of capability response, supported limit value can be published. But, if the server supports mailbox specific limit, then APPENDLIMIT value will be omitted as part of Capability response. It will send only APPENDLIMIT string in the capability, then client can always get the mailbox specific limit as part of SELECT, LIST 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”
 
Kindly let us know, if this answers your question. Please revert back for any clarification.
 
Regards,
Jay
 
On Mon, Jul 20, 2015 at 3:29 PM, Naren <narendrasingh.bisht <at> gmail.com> wrote:
>
> Hello Working Group,
>
> We have published the first draft for draft-ietf-imapapnd-appendlimit-extension.
>
> Please review the draft and drop your comments.
>
> ion/
>
> --
> Thanks & Regards
> -Naren
>
> _______________________________________________
> imapext mailing list
>
 
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Naren | 21 Jul 00:29 2015
Picon

Review for first draft for draft-ietf-imapapnd-appendlimit-extension

Hello Working Group,

We have published the first draft for draft-ietf-imapapnd-appendlimit-extension.

Please review the draft and drop your comments.


-- 
Thanks & Regards
-Naren
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
S Moonesamy | 20 Jul 13:29 2015

Re: Imapapnd WG editor for draft-ietf-imapapnd-rfc2088bis

Hello,

Alexey will be the document editor for draft-ietf-imapapnd-rfc2088bis 
which is the second draft on our WG Charter.  The first and second 
drafts will be posted soon.  I suggest giving priority to the first draft.

Regards,
S. Moonesamy (as imapapdb WG Chair)

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

S Moonesamy | 20 Jul 13:18 2015

Re: Imapapnd WG editor for draft-ietf-imapapnd-appendlimit-extension

Hello,

Jay and Naren will be the document editors for 
draft-ietf-imapapnd-appendlimit-extension which is the first draft on 
our WG Charter.  I would appreciate if you could help them by 
reviewing the draft once it is available.

Regards,
S. Moonesamy (as imapapdb WG Chair)

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


Gmane