Re: CAP - BEEP Profile

Marshall Rose wrote:

>>I can add text that says if you get a multipart and you said "no 
>>multipart", then
>>you get a BEEP error...  Is that what you were saying, add a BEEP error?
>>    
>>
>
>no. the problem is that you have text in your draft which
>says/implies/whatever that you can put more than one mime objects in a
>single MSG/RPY/ANS without using a multipart.
>    
>that is also against beeps' rules.
>
Yes I agree - I replied to that saying: 

It (they all) should say [iCAL], as in (fixed text below):

       The BEEP "MSG" messages can only contain MIME "multipart" MIME
       objects if the other endpoint has received a CAP "CAPABILITY"
       indicating the other endpoint supports multipart MIME objects. This
       does not prevent the endpoint from sending multiple [iCAL] objects
       in a single BEEP "MSG" so long as all of the [iCAL] objects have
       the same "TARGET" property value.

An iCAL object is a BEGIN/END VCALENDAR blob.
And a single (non multipart) iCAL MIME object may contain one or
more BEGIN/END VCALENDAR objects (per RFC 2445).

This WG wanted:

    Those to still be valid as long as they all have the same TARGET.

    When they have different TARGET values, then they have to be in separate
    MIME objects.

    When the recipient does not allow multipart, then they have to be in 
separate
    BEEP ANSs.

Does that fix the issue?

-- 

 Doug Royer                     |   http://INET-Consulting.com 
 -------------------------------|-----------------------------
 [email protected]                 | Office: (208)612-INET
 http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

                We Do Standards - You Need Standards