Subject: Re: [imapext] IMAP BODY STRUCTURE

From: Alexey Melnikov <[email-masked]>
Date: Tue, 01 Sep 2015 11:19:14 +0100

On 01/09/2015 04:51, Jamie Nicolson wrote:
> As far as I can tell, RFC 3501 only requires the server to parse 
> internal messages of type message/rfc822. In fact, it might be 
> considered a violation of the IMAP protocol to provide such details 
> about a message/cpim part in the bodystructure response.
Agreed, it would be a violation without a client enabled extension.
> On Fri, Aug 28, 2015 at 7:26 PM, Nigar Sultana 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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 <tel:%2B4917112345678>
>     To: Joe User <[email-masked] <mailto:[email-masked]>>, tel:0401234567
>     Cc: tel:+358501234567 <tel:%2B358501234567>
>
These are not even email addresses, so I don't think this will work very 
well with IMAP.
>
>     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 <tel:%2B4917112345678>
>     To: Joe User <[email-masked] <mailto:[email-masked]>>
>     To: tel:0401234567
>     cc: tel:+358501234567 <tel:%2B358501234567>
>     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>
>     --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
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/imapext
>
>
>
>
> _______________________________________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/imapext

---

From: Nigar Sultana <[email-masked]>
Date: Wed, 2 Sep 2015 09:12:49 +0000 (UTC)

Yes agreed with the comments. thanks for sharing your views. 
support based on client enabled extension, does it mean client and server should use extension commands for BODYSTRUCTURE. Instead of using standard command, should client use command something like XBODYSTRUCTURE. please provide your feedback
The extension are usually published by server in capabilities. 
RegardsNigar Sultana 

     On Tuesday, 1 September 2015 3:49 PM, Alexey Melnikov <[email-masked]> wrote:

 As far as I can tell, RFC 3501 only requires the server to parse internal messages of type message/rfc822. In fact, it might be considered a violation of the IMAP protocol to provide such details about a message/cpim part in the bodystructure response. 
 Agreed, it would be a violation without a client enabled extension.
 
  On Fri, Aug 28, 2015 at 7:26 PM, Nigar Sultana <[email-masked]> wrote:
 
   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 <[email-masked]>, tel:0401234567 Cc: tel:+358501234567   
   
 These are not even email addresses, so I don't think this will work very well with IMAP. 
   
   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 <[email-masked]> 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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 Sep 2015 10:27:11 +0100

Nigar Sultana writes:
> support based on client enabled extension, does it mean client 
> and server should use extension commands for BODYSTRUCTURE. 
> Instead of using standard command, should client use command 
> something like XBODYSTRUCTURE. please provide your feedback
>

Some extensions are advertised by servers but enabled by clients, RFC6855 
is an example. Your proposal is like 6855 in that if a server were to use 
it unilaterally, a strictly parsing client would see a syntax error.

The conventional way is to use a command such as "ENABLE CPIM" to enable 
the extra bodystructure processing in the server, where CPIM is the name of 
the IMAP capability.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Sep 2015 10:29:49 +0100

On 02/09/2015 10:27, Arnt Gulbrandsen wrote:
> Nigar Sultana writes:
>> support based on client enabled extension, does it mean client and 
>> server should use extension commands for BODYSTRUCTURE. Instead of 
>> using standard command, should client use command something like 
>> XBODYSTRUCTURE. please provide your feedback
>>
> Some extensions are advertised by servers but enabled by clients, 
> RFC6855 is an example. Your proposal is like 6855 in that if a server 
> were to use it unilaterally, a strictly parsing client would see a 
> syntax error.
>
> The conventional way is to use a command such as "ENABLE CPIM" to 
> enable the extra bodystructure processing in the server, where CPIM is 
> the name of the IMAP capability.
Yes, the client sends ENABLE CPIM first, then all BODYSTRUCTURE returned 
should contain extended data.

Nigar, feel free to publish ABNF for how you want to return extended 
data about CPIM messages before you implement. If this extension is done 
right, it might be included in IMAP update at some point.