From owner-ietf-calendar@mail.imc.org  Tue Sep  3 08:43:14 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24276
	for <calsch-archive@lists.ietf.org>; Tue, 3 Sep 2002 08:43:14 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g83CXxF28113
	for ietf-calendar-bks; Tue, 3 Sep 2002 05:33:59 -0700 (PDT)
Received: from mail.samsungcontact.com (host195-89-159-51.uk.regusnet.com [195.89.159.51])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g83CXv228107
	for <ietf-calendar@imc.org>; Tue, 3 Sep 2002 05:33:57 -0700 (PDT)
Received: from mail.samsungcontact.com (root@localhost)
	by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g83CXkJ06626
	for <ietf-calendar@imc.org>; Tue, 3 Sep 2002 13:33:47 +0100
Received: from samsungcontact.com (host195-89-159-62.uk.regusnet.com 195.89.159.62)
        by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0)
        via ESMTP; Tue, 03 Sep 2002 13:33:47 +0100 (BST)
Message-ID: <3D74AC2A.4030802@samsungcontact.com>
Date: Tue, 03 Sep 2002 13:33:46 +0100
From: Mark Davidson <markd@samsungcontact.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: CAL-QUERY definition
References: <3D5287CA.1060409@samsungcontact.com> <H0000069000d4821.1030537994.mail.samsungcontact.com@MHS>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


I just noticed another problem in the CAL-QUERY definition (in the snapshot).

In:

              cap-factor  = cap-colval SP cap-oper SP col-value
                          / cap-colval SP "NOT LIKE" SP col-value
                          / cap-colval SP "LIKE" SP col-value
                          / cap-colval SP "IS NULL"
                          / cap-colval SP "IS NOT NULL"
                          / col-value SP "NOT IN" cap-colval"
                          / col-value SP "IN" cap-colval"

              cap-colval     = cap-col
                          / "PARAM(" cap-col "," cap-param ")"

              cap-param   = ; Any parameter that may be contained in the cap-col
                            ; in the supplied PARAM() function

              col-value   = col-literal
                          / "STATE()"
                          / "SELF()"
                          / "CAL-OWNERS()"
                          / "CAL-OWNERS(" cal-address ")"
                          / "CURRENT-TARGET()"


STATE() should not be a col-value, it should be a cap-colval.(You don't do =STATE() you
use STATE()= )

So:
              cap-factor  = cap-colval SP cap-oper SP col-value
                          / cap-colval SP "NOT LIKE" SP col-value
                          / cap-colval SP "LIKE" SP col-value
                          / cap-colval SP "IS NULL"
                          / cap-colval SP "IS NOT NULL"
                          / col-value SP "NOT IN" cap-colval"
                          / col-value SP "IN" cap-colval"

              cap-colval     = cap-col
                          / "STATE()"
                          / "PARAM(" cap-col "," cap-param ")"

              cap-param   = ; Any parameter that may be contained in the cap-col
                            ; in the supplied PARAM() function

              col-value   = col-literal
                          / "SELF()"
                          / "CAL-OWNERS()"
                          / "CAL-OWNERS(" cal-address ")"
                          / "CURRENT-TARGET()"


Also the example just before the definition has:

          (a) SELECT VEVENT.<a-property-name> FROM VEVENT

           shouldn't this be

          (a) SELECT <a-property-name> FROM VEVENT



Mark Davidson



From owner-ietf-calendar@mail.imc.org  Wed Sep  4 12:56:46 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10111
	for <calsch-archive@lists.ietf.org>; Wed, 4 Sep 2002 12:56:46 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g84Gntx28036
	for ietf-calendar-bks; Wed, 4 Sep 2002 09:49:55 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Gns228029
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 09:49:54 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 8AF6815528; Wed,  4 Sep 2002 18:49:54 +0200 (CEST)
Date: Wed, 4 Sep 2002 18:49:54 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: TARGET in VQUERY (was: No comments on my proposals?)
Message-ID: <20020904164954.GB26483@inet.it>
References: <1028739969.18782.107.camel@c-1241.in.steltor.com> <3D67B969.2430CA5E@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D67B969.2430CA5E@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Sat, Aug 24, 2002 at 10:50:49AM -0600, Doug Royer wrote:
> Patrice Lapierre wrote:
> > 
> > The addition of a TARGET property in VQUERY addresses this issue,
> > and may even allow a more efficient implementation since we don't
> > need to search all the VAGENDAs to find the VQUERY.
> 
> I agree. I have seen no objection, so I added to the CAP source.
> 

I don't see this added in the latest draft - I guess it should appear
in section 8.6, that is:

     queryc    =  "BEGIN" ":" "VQUERY" CRLF
                queryprop
                "END" ":" "VCAR" CRLF

     queryprop = 1*(

                 ; the following are OPTIONAL but MUST NOT occur
                 ; more than once
                 ;
                 queryid / target

                 ; the following are OPTIONAL, and MAY occur
                 ; more than once
                 ;
                 / name / x-prop / iana-prop

                 ; the following MUST occur at least once.
                 ;
                 / query

                )

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep  4 13:02:23 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10338
	for <calsch-archive@lists.ietf.org>; Wed, 4 Sep 2002 13:02:23 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g84GtMZ28410
	for ietf-calendar-bks; Wed, 4 Sep 2002 09:55:22 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84GtL228406
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 09:55:21 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 7B87615528; Wed,  4 Sep 2002 18:55:22 +0200 (CEST)
Date: Wed, 4 Sep 2002 18:55:22 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: QUERY * TARGET * METHOD
Message-ID: <20020904165522.GC26483@inet.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


Hi all,

what happens if I send:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: TARGET:relcal3
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT
   C: QUERY:SELECT * FROM VTODO
   C: END:VQUERY
   C: END:VCALENDAR

I should get back one component per TARGET, one component per METHOD
and one component per QUERY - in what order? I would expect the order
I mentioned, right? Note that this IS relevant, as the returned
data doesn't contain any mention of the TARGET it comes from.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep  4 13:03:13 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10436
	for <calsch-archive@lists.ietf.org>; Wed, 4 Sep 2002 13:03:13 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g84Gwmt28498
	for ietf-calendar-bks; Wed, 4 Sep 2002 09:58:48 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Gwl228493
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 09:58:47 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id B640315528; Wed,  4 Sep 2002 18:58:48 +0200 (CEST)
Date: Wed, 4 Sep 2002 18:58:48 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Atomic operations or not
Message-ID: <20020904165848.GD26483@inet.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


Hi all,

in section 9.5 states:



 If the REQUEST-STATUS is 2.0, then the entire modification was successful.

If any error occurred:

No component will be changed at all. That is, it will appear just as it was prior to the modify and the CAP server SHOULD return a REQUEST-STATUS for each error that occurred.

There MUST BE at least one error reported.



I can't help but wonder why this should only apply to MODIFY and not
other commands which change data. IMHO we want the same requirement
for all cases.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep  4 13:25:07 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11793
	for <calsch-archive@lists.ietf.org>; Wed, 4 Sep 2002 13:25:07 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g84HJmI01774
	for ietf-calendar-bks; Wed, 4 Sep 2002 10:19:48 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84HJl201770
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 10:19:47 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 0559615528; Wed,  4 Sep 2002 19:19:48 +0200 (CEST)
Date: Wed, 4 Sep 2002 19:19:48 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: GET-CAPABILITY
Message-ID: <20020904171948.GF26483@inet.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


Hi all,

In section 9.3 MAX-COMPONENT-SIZE appears as mandatory (occurs 1).
However its description says that it can be absent.
On the other hand, RECUR-LIMIT is described as using 0 to mean no
restriction. IMHO they should be consistent.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep  4 13:31:05 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12107
	for <calsch-archive@lists.ietf.org>; Wed, 4 Sep 2002 13:31:04 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g84HH8x01564
	for ietf-calendar-bks; Wed, 4 Sep 2002 10:17:08 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84HH7201557
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 10:17:07 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id B89AB15528; Wed,  4 Sep 2002 19:17:08 +0200 (CEST)
Date: Wed, 4 Sep 2002 19:17:08 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Reply to MODIFY command
Message-ID: <20020904171708.GE26483@inet.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


Hi all,

section 9.5 states:


 If multiple components are selected, then what uniquely identified the component MUST BE returned (UID, QUERYID, ...) if the component contains a unique identifier. If not sufficient information to uniquely identify the modified components MUST BE returned in the reply. 


I find this hard to understand (uniquely identifying multiple things
sounds like an oxymoron to me), would it be possible to elaborate on
this and maybe add a couple of examples?

Bye,
	andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep  4 14:03:30 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13596
	for <calsch-archive@lists.ietf.org>; Wed, 4 Sep 2002 14:03:29 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g84HpVv02487
	for ietf-calendar-bks; Wed, 4 Sep 2002 10:51:31 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84HpT202483
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 10:51:29 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g84HpSbB029237
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 10:51:31 -0700
Message-ID: <3D7647EE.8EC6EA94@Royer.com>
Date: Wed, 04 Sep 2002 11:50:38 -0600
From: Doug Royer <Doug@royer.com>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
CC: ietf-calendar@imc.org
Subject: Re: TARGET in VQUERY (was: No comments on my proposals?)
References: <1028739969.18782.107.camel@c-1241.in.steltor.com> <3D67B969.2430CA5E@Royer.com> <20020904164954.GB26483@inet.it>
Content-Type: multipart/mixed;
 boundary="------------2123859E2115C78DC8883DEC"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------2123859E2115C78DC8883DEC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> On Sat, Aug 24, 2002 at 10:50:49AM -0600, Doug Royer wrote:
> > Patrice Lapierre wrote:
> > >
> > > The addition of a TARGET property in VQUERY addresses this issue,
> > > and may even allow a more efficient implementation since we don't
> > > need to search all the VAGENDAs to find the VQUERY.
> >
> > I agree. I have seen no objection, so I added to the CAP source.

True, I did not push it yet as I have often discoverd that
people tend to ignore an issue - until you have said 'done'.
--------------2123859E2115C78DC8883DEC
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------2123859E2115C78DC8883DEC--



From owner-ietf-calendar@mail.imc.org  Wed Sep  4 14:25:05 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14295
	for <calsch-archive@lists.ietf.org>; Wed, 4 Sep 2002 14:25:05 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g84IFUp03421
	for ietf-calendar-bks; Wed, 4 Sep 2002 11:15:30 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84IFT203417
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 11:15:29 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g84IFTbB029428
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 11:15:31 -0700
Message-ID: <3D764D8E.6297A7D2@Royer.com>
Date: Wed, 04 Sep 2002 12:14:38 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Reply to MODIFY command
References: <20020904171708.GE26483@inet.it>
Content-Type: multipart/mixed;
 boundary="------------5EE8AB260F17A2110E5C658D"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------5EE8AB260F17A2110E5C658D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> Hi all,
> 
> section 9.5 states:
> 
>  If multiple components are selected, then what uniquely identified the
> component MUST BE returned (UID, QUERYID, ...) if the component contains
> a unique identifier. If not sufficient information to uniquely identify
> the modified components MUST BE returned in the reply.
> 
> I find this hard to understand (uniquely identifying multiple things
> sounds like an oxymoron to me), would it be possible to elaborate on
> this and maybe add a couple of examples?
> 

Was that not covered in the ABNF for the reply? I think
it lists what has to be returned for each component type.
Or are you saying it is incomplete or inaccurate?
--------------5EE8AB260F17A2110E5C658D
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------5EE8AB260F17A2110E5C658D--



From owner-ietf-calendar@mail.imc.org  Wed Sep  4 14:27:46 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14418
	for <calsch-archive@lists.ietf.org>; Wed, 4 Sep 2002 14:27:45 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g84IDL603380
	for ietf-calendar-bks; Wed, 4 Sep 2002 11:13:21 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84IDK203376
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 11:13:20 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g84IDKbB029399
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 11:13:22 -0700
Message-ID: <3D764D0D.F3FC970A@Royer.com>
Date: Wed, 04 Sep 2002 12:12:29 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: QUERY * TARGET * METHOD
References: <20020904165522.GC26483@inet.it>
Content-Type: multipart/mixed;
 boundary="------------7CFED16CBFA72D78D5A05804"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------7CFED16CBFA72D78D5A05804
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> Hi all,
> 
> what happens if I send:
> 
>    C: Content-Type: text/calendar
>    C:
>    C: BEGIN:VCALENDAR
>    C: VERSION:2.0
>    C: PRODID:-//someone's prodid
>    C: CMD:SEARCH
>    C: TARGET:relcal2
>    C: TARGET:relcal3
>    C: BEGIN:VQUERY
>    C: QUERY:SELECT * FROM VEVENT
>    C: QUERY:SELECT * FROM VTODO
>    C: END:VQUERY
>    C: END:VCALENDAR
> 
> I should get back one component per TARGET, one component per METHOD
> and one component per QUERY - in what order? I would expect the order
> I mentioned, right? Note that this IS relevant, as the returned
> data doesn't contain any mention of the TARGET it comes from.

One object (see 9.1.4 for details) per TARGET, each
object can contain multiple components, as long
as they are all the same METHOD.


In: 9.1.4 CREATE Command

	...
   Response:

   One iCalendar object per TARGET property MUST BE returned.

   The REPLY of any "CREATE" command is:

   ...



And 9.1.4 CREATE Command

 Seems this needs to be moved to "9.1 CAP Commands (CMD)"
 and applied to all commands:

	...
   When there are multiple TARGET values in the original command object
   then the replies MUST BE in the exact same order as they were
   provided to the CS.  The same is true for the objects created, their
	...
--------------7CFED16CBFA72D78D5A05804
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------7CFED16CBFA72D78D5A05804--



From owner-ietf-calendar@mail.imc.org  Wed Sep  4 14:51:38 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15630
	for <calsch-archive@lists.ietf.org>; Wed, 4 Sep 2002 14:51:38 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g84IYJd03750
	for ietf-calendar-bks; Wed, 4 Sep 2002 11:34:19 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84IYI203746
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 11:34:18 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g84IYHbB029548
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Wed, 4 Sep 2002 11:34:20 -0700
Message-ID: <3D7651F7.DF4AA512@Royer.com>
Date: Wed, 04 Sep 2002 12:33:27 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: GET-CAPABILITY
References: <20020904171948.GF26483@inet.it>
Content-Type: multipart/mixed;
 boundary="------------C9BF75105BBD6C5D48C82F77"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------C9BF75105BBD6C5D48C82F77
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> Hi all,
> 
> In section 9.3 MAX-COMPONENT-SIZE appears as mandatory (occurs 1).
> However its description says that it can be absent.
>
> On the other hand, RECUR-LIMIT is described as using 0 to mean no
> restriction. IMHO they should be consistent.

I agree, it should be required, and ZERO should mean unlimited.
--------------C9BF75105BBD6C5D48C82F77
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------C9BF75105BBD6C5D48C82F77--



From owner-ietf-calendar@mail.imc.org  Thu Sep  5 06:10:45 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13862
	for <calsch-archive@lists.ietf.org>; Thu, 5 Sep 2002 06:10:44 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g85A2pv08292
	for ietf-calendar-bks; Thu, 5 Sep 2002 03:02:51 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g85A2l208288
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 03:02:47 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id BE11415528; Thu,  5 Sep 2002 12:02:46 +0200 (CEST)
Date: Thu, 5 Sep 2002 12:02:46 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: Reply to MODIFY command
Message-ID: <20020905100246.GA29009@inet.it>
References: <20020904171708.GE26483@inet.it> <3D764D8E.6297A7D2@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D764D8E.6297A7D2@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g85A2m208289
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


On Wed, Sep 04, 2002 at 12:14:38PM -0600, Doug Royer wrote:
> Andrea Campi wrote:
> > 
> > Hi all,
> > 
> > section 9.5 states:
> > 
> >  If multiple components are selected, then what uniquely identified the
> > component MUST BE returned (UID, QUERYID, ...) if the component contains
> > a unique identifier. If not sufficient information to uniquely identify
> > the modified components MUST BE returned in the reply.
> > 
> > I find this hard to understand (uniquely identifying multiple things
> > sounds like an oxymoron to me), would it be possible to elaborate on
> > this and maybe add a couple of examples?
> > 
> 
> Was that not covered in the ABNF for the reply? I think
> it lists what has to be returned for each component type.
> Or are you saying it is incomplete or inaccurate?

Yes, that's part of the problem - there's no modify-reply ABNF.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Thu Sep  5 06:30:45 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14161
	for <calsch-archive@lists.ietf.org>; Thu, 5 Sep 2002 06:30:45 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g85AQ4310065
	for ietf-calendar-bks; Thu, 5 Sep 2002 03:26:04 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g85AQ3210058
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 03:26:03 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 28A1115528; Thu,  5 Sep 2002 12:26:03 +0200 (CEST)
Date: Thu, 5 Sep 2002 12:26:03 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: QUERY * TARGET * METHOD
Message-ID: <20020905102603.GB29009@inet.it>
References: <20020904165522.GC26483@inet.it> <3D764D0D.F3FC970A@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D764D0D.F3FC970A@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Wed, Sep 04, 2002 at 12:12:29PM -0600, Doug Royer wrote:
> Andrea Campi wrote:
> > 
> > Hi all,
> > 
> > what happens if I send:
> > 
> >    C: Content-Type: text/calendar
> >    C:
> >    C: BEGIN:VCALENDAR
> >    C: VERSION:2.0
> >    C: PRODID:-//someone's prodid
> >    C: CMD:SEARCH
> >    C: TARGET:relcal2
> >    C: TARGET:relcal3
> >    C: BEGIN:VQUERY
> >    C: QUERY:SELECT * FROM VEVENT
> >    C: QUERY:SELECT * FROM VTODO
> >    C: END:VQUERY
> >    C: END:VCALENDAR
> > 
> > I should get back one component per TARGET, one component per METHOD
> > and one component per QUERY - in what order? I would expect the order
> > I mentioned, right? Note that this IS relevant, as the returned
> > data doesn't contain any mention of the TARGET it comes from.
> 
> One object (see 9.1.4 for details) per TARGET, each
> object can contain multiple components, as long
> as they are all the same METHOD.

Yes, that's the easy case, and *I AM* looking at 9.1.4. You didn't
answer the query, but maybe I wasnt't clear, so I'll provide an
example to what I think will be returned for the above query:

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal2
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal2
   S: METHOD:REQUEST
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal2
   S: METHOD:REPLY
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal3
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal3
   S: METHOD:REQUEST
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal3
   S: METHOD:REPLY
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR


Where inside each of the VREPLY component, you have all matching
objects for all the queries, handled as a union.


Is this right?


> In: 9.1.4 CREATE Command
> 
> 	...
>    Response:
> 
>    One iCalendar object per TARGET property MUST BE returned.
> 
>    The REPLY of any "CREATE" command is:
> 
> And 9.1.4 CREATE Command
> 
>  Seems this needs to be moved to "9.1 CAP Commands (CMD)"
>  and applied to all commands:
> 
> 	...
>    When there are multiple TARGET values in the original command object
>    then the replies MUST BE in the exact same order as they were
>    provided to the CS.  The same is true for the objects created, their
> 	...

I agree, both sentences should be moved.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Thu Sep  5 10:02:34 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19759
	for <calsch-archive@lists.ietf.org>; Thu, 5 Sep 2002 10:02:33 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g85Dqat23454
	for ietf-calendar-bks; Thu, 5 Sep 2002 06:52:36 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g85DqZ223449
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 06:52:35 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 2C91515528; Thu,  5 Sep 2002 15:52:36 +0200 (CEST)
Date: Thu, 5 Sep 2002 15:52:36 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: DELETED objects
Message-ID: <20020905135236.GC29009@inet.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


Section 2.2 (at its very end) says:

>	Finally, the CUA could do a "DELETE" or change their state to "DELETED" for all of these now old scheduling requests in the CS. See [iTIP] for details on resolving multiple [iTIP] scheduling entries. 


There is no way to "change state to DELETED" other than using the
DELETE command, so this period should read:

>	Finally, the CUA could do a "DELETE" for all of these now old scheduling requests in the CS. See [iTIP] for details on resolving multiple [iTIP] scheduling entries. 




Also, in 1.3:

       3.  A marked for delete component has its state set to DELETE. To retrieve any deleted object, simply do a query asking for any objects that were stored with its state set to "DELETED". By default objects marked for delete are not returned. The CUA must specifically ask for marked for delete objects.


It might not be obvious but in addition to this, a query MUST NOT
return objects in the DELETED state and in other states, as there
would be no way to distinguish between them. I wonder if this warrants
a brief note here.


Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Thu Sep  5 11:08:20 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22204
	for <calsch-archive@lists.ietf.org>; Thu, 5 Sep 2002 11:08:20 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g85Ensr27474
	for ietf-calendar-bks; Thu, 5 Sep 2002 07:49:54 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g85Enr227470
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 07:49:53 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g85EnqbB005271
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 07:49:54 -0700
Message-ID: <3D776ED3.9DB8DBCE@Royer.com>
Date: Thu, 05 Sep 2002 08:48:51 -0600
From: Doug Royer <Doug@royer.com>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
CC: ietf-calendar@imc.org
Subject: Re: QUERY * TARGET * METHOD
References: <20020904165522.GC26483@inet.it> <3D764D0D.F3FC970A@Royer.com> <20020905102603.GB29009@inet.it>
Content-Type: multipart/mixed;
 boundary="------------E97FF78CE565F0482F99B1DA"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------E97FF78CE565F0482F99B1DA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:

> Yes, that's the easy case, and *I AM* looking at 9.1.4. You didn't
> answer the query, but maybe I wasnt't clear, so I'll provide an
> example to what I think will be returned for the above query:
> ...

Yes. And the objects for the same TARGET that have the
same method could be in the same MIME object. So some
of the text/calendar replies could have multiple VCALENDARS
and some with a single VCALENDAR. 

> Where inside each of the VREPLY component, you have all matching
> objects for all the queries, handled as a union.

'Union'? If you mean one right after the other - yes.
--------------E97FF78CE565F0482F99B1DA
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------E97FF78CE565F0482F99B1DA--



From owner-ietf-calendar@mail.imc.org  Thu Sep  5 11:08:24 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22220
	for <calsch-archive@lists.ietf.org>; Thu, 5 Sep 2002 11:08:23 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g85EqRZ27615
	for ietf-calendar-bks; Thu, 5 Sep 2002 07:52:27 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g85EqQ227610
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 07:52:26 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g85EqObB005297
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 07:52:27 -0700
Message-ID: <3D776F6C.770DD3B0@Royer.com>
Date: Thu, 05 Sep 2002 08:51:24 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: DELETED objects
References: <20020905135236.GC29009@inet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Andrea Campi wrote:
> 
> Section 2.2 (at its very end) says:
> 
> Finally, the CUA could do a "DELETE" or change their state to
> "DELETED" for all of these now old scheduling requests in the CS. See
> [iTIP] for details on resolving multiple [iTIP] scheduling entries.
> 
> There is no way to "change state to DELETED" other than using the
> DELETE command, so this period should read:

> Finally, the CUA could do a "DELETE" for all of these now old
> scheduling requests in the CS. See [iTIP] for details on resolving
> multiple [iTIP] scheduling entries.

Yes. 

> Also, in 1.3:
> 
> 3.  A marked for delete component has its state set to DELETE. To
> retrieve any deleted object, simply do a query asking for any objects
> that were stored with its state set to "DELETED". By default objects
> marked for delete are not returned. The CUA must specifically ask for
>  marked for delete objects.
> 
> It might not be obvious but in addition to this, a query MUST NOT
> return objects in the DELETED state and in other states, as there
> would be no way to distinguish between them. I wonder if this warrants
> a brief note here.

True. If I don't see any objections, I'll add a note.

Thanks again!
-Doug


From owner-ietf-calendar@mail.imc.org  Thu Sep  5 12:27:48 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24538
	for <calsch-archive@lists.ietf.org>; Thu, 5 Sep 2002 12:27:47 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g85GEFL01105
	for ietf-calendar-bks; Thu, 5 Sep 2002 09:14:15 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g85GEE201101
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 09:14:14 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 11FEA15528; Thu,  5 Sep 2002 18:14:15 +0200 (CEST)
Date: Thu, 5 Sep 2002 18:14:15 +0200
From: Andrea Campi <a.campi@inet.it>
To: Doug Royer <Doug@royer.com>
Cc: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: QUERY * TARGET * METHOD
Message-ID: <20020905161415.GF29009@inet.it>
References: <20020904165522.GC26483@inet.it> <3D764D0D.F3FC970A@Royer.com> <20020905102603.GB29009@inet.it> <3D776ED3.9DB8DBCE@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D776ED3.9DB8DBCE@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g85GEE201102
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


On Thu, Sep 05, 2002 at 08:48:51AM -0600, Doug Royer wrote:
> Andrea Campi wrote:
> 
> > Yes, that's the easy case, and *I AM* looking at 9.1.4. You didn't
> > answer the query, but maybe I wasnt't clear, so I'll provide an
> > example to what I think will be returned for the above query:
> > ...
> 
> Yes. And the objects for the same TARGET that have the
> same method could be in the same MIME object. So some
> of the text/calendar replies could have multiple VCALENDARS
> and some with a single VCALENDAR. 

Sorry? Objects for the same TARGET with the same METHOD would be all
inside a single VCALENDAR, I expect. Or do you mean objects for the
same TARGET with the same METHOD, but coming from different queries?

> > Where inside each of the VREPLY component, you have all matching
> > objects for all the queries, handled as a union.
> 
> 'Union'? If you mean one right after the other - yes.

Well, section 6.1.1 says:

#  When multiple QUERY properties are supplied in a single VQUERY component, the results returned are the same as the results returned for multiple VQUERY components having each a single QUERY property and the results are return in the same order as the VQUERYs were specified in the original command.


So I guess you are right, it's not a boolean union operation (by the
way, what happens if two queries match the same object? Is it returned
twice?).


Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Thu Sep  5 13:38:48 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28194
	for <calsch-archive@lists.ietf.org>; Thu, 5 Sep 2002 13:38:47 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g85HTYe07247
	for ietf-calendar-bks; Thu, 5 Sep 2002 10:29:34 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g85HTW207243
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 10:29:32 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g85HTWbB006444
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 5 Sep 2002 10:29:34 -0700
Message-ID: <3D77943E.8E862190@Royer.com>
Date: Thu, 05 Sep 2002 11:28:30 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: QUERY * TARGET * METHOD
References: <20020904165522.GC26483@inet.it> <3D764D0D.F3FC970A@Royer.com> <20020905102603.GB29009@inet.it> <3D776ED3.9DB8DBCE@Royer.com> <20020905161415.GF29009@inet.it>
Content-Type: multipart/mixed;
 boundary="------------48CFCB5B69C750BF313E65B0"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------48CFCB5B69C750BF313E65B0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> On Thu, Sep 05, 2002 at 08:48:51AM -0600, Doug Royer wrote:
> > Andrea Campi wrote:
> >
> > > Yes, that's the easy case, and *I AM* looking at 9.1.4. You didn't
> > > answer the query, but maybe I wasnt't clear, so I'll provide an
> > > example to what I think will be returned for the above query:
> > > ...
> >
> > Yes. And the objects for the same TARGET that have the
> > same method could be in the same MIME object. So some
> > of the text/calendar replies could have multiple VCALENDARS
> > and some with a single VCALENDAR.
> 
> Sorry? Objects for the same TARGET with the same METHOD would be all
> inside a single VCALENDAR, I expect.

OR - they could each be in a separate VCALENDAR in the same
MIME object - iCalendar allows both, so CAP would need
to expect both.

> Or do you mean objects for the same TARGET with the same METHOD,
> but coming from different queries?

No.

> > > Where inside each of the VREPLY component, you have all matching
> > > objects for all the queries, handled as a union.
> >
> > 'Union'? If you mean one right after the other - yes.
> 
> Well, section 6.1.1 says:
> 
> #  When multiple QUERY properties are supplied in a single VQUERY
> component, the results returned are the same as the results returned
> for multiple VQUERY components having each a single QUERY property and
> the results are return in the same order as the VQUERYs were specified
> in the original command.
> 
> So I guess you are right, it's not a boolean union operation (by the
> way, what happens if two queries match the same object? Is it returned
> twice?).

I would say Yes.
--------------48CFCB5B69C750BF313E65B0
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------48CFCB5B69C750BF313E65B0--



From owner-ietf-calendar@mail.imc.org  Fri Sep  6 06:50:31 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29467
	for <calsch-archive@lists.ietf.org>; Fri, 6 Sep 2002 06:50:30 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g86AftE23146
	for ietf-calendar-bks; Fri, 6 Sep 2002 03:41:55 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g86Afrk23142
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 03:41:54 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 1885E15528; Fri,  6 Sep 2002 12:41:53 +0200 (CEST)
Date: Fri, 6 Sep 2002 12:41:53 +0200
From: Andrea Campi <a.campi@inet.it>
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Reply semantics [Was: QUERY * TARGET * METHOD]
Message-ID: <20020906104152.GC32393@inet.it>
References: <20020904165522.GC26483@inet.it> <3D764D0D.F3FC970A@Royer.com> <20020905102603.GB29009@inet.it> <3D776ED3.9DB8DBCE@Royer.com> <20020905161415.GF29009@inet.it> <3D77943E.8E862190@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D77943E.8E862190@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Thu, Sep 05, 2002 at 11:28:30AM -0600, Doug Royer wrote:
> > 
> > Sorry? Objects for the same TARGET with the same METHOD would be all
> > inside a single VCALENDAR, I expect.
> 
> OR - they could each be in a separate VCALENDAR in the same
> MIME object - iCalendar allows both, so CAP would need
> to expect both.

Sorry but I don't agree. It's not an issue of data format, rather,
this is about the semantics of the SEARCH command (and the others, too).
As long as the resulting data is valid under iCalendar, it's CAP that
must dictate how the reply to the command; and I do agree with the
people who said on the list that it's not good to have different ways
of doing things.

The issue at hand is easy, and could be formulated as: if I send one
VCALENDAR object containing 1+ commands, what should I expect to get
back?
Ideally, it would be good to say: one.
Less ideally, the answer is: one per METHOD times one per TARGET.
Now you are saying the answer is actually "how many the server wants
as long as iCalendar rules are respected"??

Again, I don't think this point can be left as a generic "you can do
anything iCalendar permits". Since in iCalendar there's no such thing
as a command nor a reply, it's up to CAP to define this aspect, and
we can and should define it unambiguously.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Fri Sep  6 09:56:42 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03956
	for <calsch-archive@lists.ietf.org>; Fri, 6 Sep 2002 09:56:42 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g86Di1Q03049
	for ietf-calendar-bks; Fri, 6 Sep 2002 06:44:01 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g86Di0k03045
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 06:44:00 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 605201552C; Fri,  6 Sep 2002 15:43:55 +0200 (CEST)
Date: Fri, 6 Sep 2002 15:43:55 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Ordering of results
Message-ID: <20020906134355.GF32393@inet.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


Section 6.1.1.7 says:

 Sorting will take place in the order the columns are supplied in the QUERY command. The CS MUST sort at least the first column. The CS MAY sort additional columns. 


However, it does not say what sorting, if any, is performed on:

SELECT * FROM VEVENT


Note that according to the ABNF, it's not legal to do:

SELECT DTSTART,* FROM VEVENT


Is this, intended, or should:

cap-cols    = cap-col / ( cap-cols "," cap-col)
                        / "*"

be changed to:

cap-cols    = cap-col / ( cap-col "," cap-cols)
                        / "*"


Also, the ABNF is still not right:
 - cap-col should allow component.property, but doesn't
 - col-value can't appear on the left side of an operator (well, except
IN), so you can't write STATE()='BOOKED'

Sorry if you've simply not gotten around to do it yet, just want to
be sure they're not forgotten.


While here, I noted that in 6.1.1.3 OWNER() got renamed to CAL-OWNERS();
however, section 6.1.1.1 already discusses the same.


-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Fri Sep  6 12:26:40 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11614
	for <calsch-archive@lists.ietf.org>; Fri, 6 Sep 2002 12:26:39 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g86GI5I10435
	for ietf-calendar-bks; Fri, 6 Sep 2002 09:18:05 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g86GI4k10431
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 09:18:04 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g86GI4bB015662
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 09:18:06 -0700
Message-ID: <3D78D45D.C8B640BF@Royer.com>
Date: Fri, 06 Sep 2002 10:14:21 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Ordering of results
References: <20020906134355.GF32393@inet.it>
Content-Type: multipart/mixed;
 boundary="------------ABF16550B6B668FF24FA15EA"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------ABF16550B6B668FF24FA15EA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> Section 6.1.1.7 says:
> 
>  Sorting will take place in the order the columns are supplied in
> the QUERY command. The CS MUST sort at least the first column. The CS
> MAY sort additional columns.
> 
> However, it does not say what sorting, if any, is performed on:
> 
> SELECT * FROM VEVENT

Please re-read 6.1.1.7
--------------ABF16550B6B668FF24FA15EA
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------ABF16550B6B668FF24FA15EA--



From owner-ietf-calendar@mail.imc.org  Fri Sep  6 12:30:23 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11831
	for <calsch-archive@lists.ietf.org>; Fri, 6 Sep 2002 12:30:23 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g86G9Cx10239
	for ietf-calendar-bks; Fri, 6 Sep 2002 09:09:12 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g86G9Bk10235
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 09:09:11 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g86G8xbB015600
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 09:09:12 -0700
Message-ID: <3D78D23C.28C26EDF@Royer.com>
Date: Fri, 06 Sep 2002 10:05:16 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Reply semantics [Was: QUERY * TARGET * METHOD]
References: <20020904165522.GC26483@inet.it> <3D764D0D.F3FC970A@Royer.com> <20020905102603.GB29009@inet.it> <3D776ED3.9DB8DBCE@Royer.com> <20020905161415.GF29009@inet.it> <3D77943E.8E862190@Royer.com> <20020906104152.GC32393@inet.it>
Content-Type: multipart/mixed;
 boundary="------------2ED4A0F1F6C0E686E6F2943A"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------2ED4A0F1F6C0E686E6F2943A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> On Thu, Sep 05, 2002 at 11:28:30AM -0600, Doug Royer wrote:
> > >
> > > Sorry? Objects for the same TARGET with the same METHOD would be all
> > > inside a single VCALENDAR, I expect.
> >
> > OR - they could each be in a separate VCALENDAR in the same
> > MIME object - iCalendar allows both, so CAP would need
> > to expect both.
> 
> Sorry but I don't agree. It's not an issue of data format, rather,
> this is about the semantics of the SEARCH command (and the others, too).
> As long as the resulting data is valid under iCalendar, it's CAP that
> must dictate how the reply to the command; and I do agree with the
> people who said on the list that it's not good to have different ways
> of doing things.
>
> The issue at hand is easy, and could be formulated as: if I send one
> VCALENDAR object containing 1+ commands, what should I expect to get
> back?
> Ideally, it would be good to say: one.
> Less ideally, the answer is: one per METHOD times one per TARGET.
> Now you are saying the answer is actually "how many the server wants
> as long as iCalendar rules are respected"??

Same with iMIP - nothing new.

> Again, I don't think this point can be left as a generic "you can do
> anything iCalendar permits". Since in iCalendar there's no such thing
> as a command nor a reply, it's up to CAP to define this aspect, and
> we can and should define it unambiguously.

With iMIP you can now get one VCALENDAR per MIME object with
multiple CALENDARS in that single MIME object or you could get
multiple MIME objects, each with one VCALENDAR.

Some iMIP implementations can support multipart/<valid> and
others do not. Sometimes you will get multipart/<valid> and
other times you will get separate MIME objects each with
a single body part.

It is not something new.

Currently their is no place that says that that a CUA must
or must not implement multipart/<valid>. So the ambiguity
remains. 244[567] ignored this issue. Now we have to live
with the fact that those are all valid iCalendar objects
in implementations. Which is why I want the 'MULTIPART:...'
capability property in CAP (and I have not seen any objections).

However the single or multiple VCALENDAR objects per MIME object
is not optional. It is explicitly allowed in 2445.

And what is the end effect difference to the calendar - 'nothing'.
All of the VCALENDAR objects must be processed as they come in.
No matter how many or few are in each MIME object.
--------------2ED4A0F1F6C0E686E6F2943A
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------2ED4A0F1F6C0E686E6F2943A--



From owner-ietf-calendar@mail.imc.org  Fri Sep  6 12:31:59 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11956
	for <calsch-archive@lists.ietf.org>; Fri, 6 Sep 2002 12:31:58 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g86GNCU11074
	for ietf-calendar-bks; Fri, 6 Sep 2002 09:23:12 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g86GNAk11067
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 09:23:11 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g86GNAbB015693
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 09:23:12 -0700
Message-ID: <3D78D58F.CD1EB5EB@Royer.com>
Date: Fri, 06 Sep 2002 10:19:27 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Ordering of results
References: <20020906134355.GF32393@inet.it>
Content-Type: multipart/mixed;
 boundary="------------47C515F4F8C6A991E85F3453"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------47C515F4F8C6A991E85F3453
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:

> Also, the ABNF is still not right:
>  - cap-col should allow component.property, but doesn't
>  - col-value can't appear on the left side of an operator (well, except
> IN), so you can't write STATE()='BOOKED'
> 
> Sorry if you've simply not gotten around to do it yet, just want to
> be sure they're not forgotten.

Was a proposal submitted? If no, then you are correct, I
have not looked at it yet.

> While here, I noted that in 6.1.1.3 OWNER() got renamed to CAL-OWNERS();
> however, section 6.1.1.1 already discusses the same.

Thanks, I'll merge and delete the duplicate.
The name change was proposed (I think by) Mark Davidson
along with the new ABNF and there were no objections from this list.
Please search the archives in case I missed something.
--------------47C515F4F8C6A991E85F3453
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------47C515F4F8C6A991E85F3453--



From owner-ietf-calendar@mail.imc.org  Fri Sep  6 13:17:08 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14407
	for <calsch-archive@lists.ietf.org>; Fri, 6 Sep 2002 13:17:07 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g86GvWV14914
	for ietf-calendar-bks; Fri, 6 Sep 2002 09:57:32 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g86GvUk14907
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 09:57:31 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002090613061017283
 for <ietf-calendar@imc.org>; Fri, 06 Sep 2002 13:06:10 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 6 Sep 2002 12:55:46 -0400
Message-ID: <3D78DE12.1080809@centivinc.com>
Date: Fri, 06 Sep 2002 12:55:46 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Reply semantics [Was: QUERY * TARGET * METHOD]
References: <20020904165522.GC26483@inet.it> <3D764D0D.F3FC970A@Royer.com> <20020905102603.GB29009@inet.it> <3D776ED3.9DB8DBCE@Royer.com> <20020905161415.GF29009@inet.it> <3D77943E.8E862190@Royer.com> <20020906104152.GC32393@inet.it> <3D78D23C.28C26EDF@Royer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Sep 2002 16:55:46.0492 (UTC) FILETIME=[3EC727C0:01C255C6]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>Currently their is no place that says that that a CUA must
>or must not implement multipart/<valid>. So the ambiguity
>remains. 244[567] ignored this issue.
>
That's because, in iMIP, it wasn't an issue; a CUA was bound up with a 
MIME-compliant MUA, which was required to support multipart.  But a CAP 
CUA is not (necessarily) an MUA.

> Now we have to live
>with the fact that those are all valid iCalendar objects
>in implementations.
>
False.  There are iMIP implementations that send multipart messages (and 
one, MS Entourage, that does it wrong), but that's irrelevant to CAP. 
 The only case in which one might try to claim it was relevant would be 
an iMIP implementation that used CAP for its backend.  But, in such a 
case, although the iMIP implementation is required to support multipart 
(since it's a MIME MUA), there is no need for it to be able to send that 
multipart up to the CS--indeed, it would be absurd, since the multipart 
probably contains non-iCalendar body parts.  Instead, it should take the 
text/calendar body part and send it to the CS.

>Which is why I want the 'MULTIPART:...'
>capability property in CAP (and I have not seen any objections).
>
You most certainly have.  I have repeatedly objected to the notion of 
supporting both multiparts and multiple VCALENDARs.  They are 
functionally equivalent, and there is no need to complicate 
interoperability by specifying both of them.  We have to pick one or the 
other.

I would lean towards multiple VCALENDARs, because a CUA probably 
contains a general-purpose text/calendar parser, which is required to 
cope with multiple VCALENDARs.  However, it is not a given; it would be 
possible to define CAP as using a profile of text/calendar, and 
forbid multiple VCALENDARs in messages transmitted over CAP.  Saying 
that CAP has to be able to support any conceivable iCalendar is like 
saying that SMTP has to be able to carry 8-bit data simply because TCP 
can carry 8-bit data.

-- 
/=================================================================\
|John Stracke      |jstracke@centivinc.com                        |
|Principal Engineer|http://www.centivinc.com                      |
|Centiv            |My opinions are my own.                       |
|=================================================================|
|"How can one conceive of a one party system in a country that has|
|over 200 varieties of cheese?" --Charles de Gaulle               |
\=================================================================/




From owner-ietf-calendar@mail.imc.org  Fri Sep  6 14:13:46 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16276
	for <calsch-archive@lists.ietf.org>; Fri, 6 Sep 2002 14:13:45 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g86HmCa16871
	for ietf-calendar-bks; Fri, 6 Sep 2002 10:48:12 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g86HmBk16867
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 10:48:11 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id EFB731552C; Fri,  6 Sep 2002 19:48:08 +0200 (CEST)
Date: Fri, 6 Sep 2002 19:48:08 +0200
From: Andrea Campi <a.campi@inet.it>
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Reply semantics [Was: QUERY * TARGET * METHOD]
Message-ID: <20020906174808.GG32393@inet.it>
References: <20020904165522.GC26483@inet.it> <3D764D0D.F3FC970A@Royer.com> <20020905102603.GB29009@inet.it> <3D776ED3.9DB8DBCE@Royer.com> <20020905161415.GF29009@inet.it> <3D77943E.8E862190@Royer.com> <20020906104152.GC32393@inet.it> <3D78D23C.28C26EDF@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D78D23C.28C26EDF@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Fri, Sep 06, 2002 at 10:05:16AM -0600, Doug Royer wrote:
> > Less ideally, the answer is: one per METHOD times one per TARGET.
> > Now you are saying the answer is actually "how many the server wants
> > as long as iCalendar rules are respected"??
> 
> Same with iMIP - nothing new.
[...]
> With iMIP you can now get one VCALENDAR per MIME object with
> multiple CALENDARS in that single MIME object or you could get
> multiple MIME objects, each with one VCALENDAR.
[...]
> remains. 244[567] ignored this issue. Now we have to live
> with the fact that those are all valid iCalendar objects
> in implementations. Which is why I want the 'MULTIPART:...'
> capability property in CAP (and I have not seen any objections).
[...]
> And what is the end effect difference to the calendar - 'nothing'.
> All of the VCALENDAR objects must be processed as they come in.
> No matter how many or few are in each MIME object.

Bah, I don't agree. A CAP server is not an iMIP store and forward
mechanism, a server can and will manipulate objects. A server with
an SQL backend can filter and sort objects in a much more efficient
way than a client, so it does make a huge difference whether my
client can expect the data to be in a meaningful order instead of
having to get all data and then sort it again one way or another.

And I surely read objections to the multipart idea, on the
same basis on which I am objecting now: iMIP and other drafts are
tools we should use, but when more than one option is available,
we can and should use the simplest one which fits the bill. And if
there are multiple ways to do the same thing, at the very least CAP
should really go into more details in explaining the alternatives,
or I can tell you we WILL have interoperability problems if a vendor
misses just one of the many alternatives.

Anyway, this is my opinion, but since it doesn't seem to be very
popular, I will now shut up until things change.


-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Fri Sep  6 17:02:49 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21361
	for <calsch-archive@lists.ietf.org>; Fri, 6 Sep 2002 17:02:49 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g86KvVO27721
	for ietf-calendar-bks; Fri, 6 Sep 2002 13:57:31 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g86KvUk27717
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 13:57:30 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g86KvTbB017539
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Fri, 6 Sep 2002 13:57:32 -0700
Message-ID: <3D7915D7.831B8F1E@Royer.com>
Date: Fri, 06 Sep 2002 14:53:43 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Reply semantics [Was: QUERY * TARGET * METHOD]
References: <20020904165522.GC26483@inet.it> <3D764D0D.F3FC970A@Royer.com> <20020905102603.GB29009@inet.it> <3D776ED3.9DB8DBCE@Royer.com> <20020905161415.GF29009@inet.it> <3D77943E.8E862190@Royer.com> <20020906104152.GC32393@inet.it> <3D78D23C.28C26EDF@Royer.com> <20020906174808.GG32393@inet.it>
Content-Type: multipart/mixed;
 boundary="------------58D86E1C7EAD0369DD135782"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------58D86E1C7EAD0369DD135782
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> On Fri, Sep 06, 2002 at 10:05:16AM -0600, Doug Royer wrote:
> > > Less ideally, the answer is: one per METHOD times one per TARGET.
> > > Now you are saying the answer is actually "how many the server wants
> > > as long as iCalendar rules are respected"??
> >
> > Same with iMIP - nothing new.
> [...]
> > With iMIP you can now get one VCALENDAR per MIME object with
> > multiple CALENDARS in that single MIME object or you could get
> > multiple MIME objects, each with one VCALENDAR.
> [...]
> > remains. 244[567] ignored this issue. Now we have to live
> > with the fact that those are all valid iCalendar objects
> > in implementations. Which is why I want the 'MULTIPART:...'
> > capability property in CAP (and I have not seen any objections).
> [...]
> > And what is the end effect difference to the calendar - 'nothing'.
> > All of the VCALENDAR objects must be processed as they come in.
> > No matter how many or few are in each MIME object.
> 
> Bah, I don't agree. A CAP server is not an iMIP store and forward
> mechanism, a server can and will manipulate objects.

I agree - and I never said that it was a store and forward
mechanism. 

I said that they will each get processed in order. It makes
no difference.
--------------58D86E1C7EAD0369DD135782
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------58D86E1C7EAD0369DD135782--



From owner-ietf-calendar@mail.imc.org  Mon Sep  9 11:00:52 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05384
	for <calsch-archive@lists.ietf.org>; Mon, 9 Sep 2002 11:00:51 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g89Eqcb13311
	for ietf-calendar-bks; Mon, 9 Sep 2002 07:52:38 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g89Eqbk13307
	for <ietf-calendar@imc.org>; Mon, 9 Sep 2002 07:52:37 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002090911010515384
 for <ietf-calendar@imc.org>; Mon, 09 Sep 2002 11:01:05 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 9 Sep 2002 10:50:42 -0400
Message-ID: <3D7CB541.2010907@centivinc.com>
Date: Mon, 09 Sep 2002 10:50:41 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF2ADE5682.675B2E20-ON85256C2F.00513312-85256C2F.00518B10@iris.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Sep 2002 14:50:42.0066 (UTC) FILETIME=[4507DF20:01C25810]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

> > (This'd be something to test for at CalConnect, BTW; I know I've 
> written
> > at least one parser that assumed there was only one iCalendar object 
> per
> > text/calendar, and I bet I'm not the only one.)
>
> Hopefully the next one will be better then.  Im sure you are not alone 
> given the sheer size of the RFCs but hopefully folks can change their 
> engines to at least accomodate the data. 

Oh, I'm sure--it's more a question of what's already been released.

-- 
/==============================================================\
|John Stracke      |jstracke@centivinc.com                     |
|Principal Engineer|http://www.centivinc.com                   |
|Centiv            |My opinions are my own.                    |
|==============================================================|
|But how do we know destroying the Van Allen belt will kill all|
|life on Earth if we don't try it?                             |
\==============================================================/




From owner-ietf-calendar@mail.imc.org  Mon Sep  9 11:00:52 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05385
	for <calsch-archive@lists.ietf.org>; Mon, 9 Sep 2002 11:00:51 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g89Eotc13256
	for ietf-calendar-bks; Mon, 9 Sep 2002 07:50:55 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g89Eosk13252
	for <ietf-calendar@imc.org>; Mon, 9 Sep 2002 07:50:54 -0700 (PDT)
To: John Stracke <jstracke@centivinc.com>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF2ADE5682.675B2E20-ON85256C2F.00513312-85256C2F.00518B10@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Mon, 9 Sep 2002 10:50:22 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/09/2002 10:44:40 AM,
	Serialize complete at 09/09/2002 10:44:40 AM
Content-Type: multipart/alternative; boundary="=_alternative 00518B0B85256C2F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 00518B0B85256C2F_=
Content-Type: text/plain; charset="US-ASCII"

John wrote:
> >>4.4 iCalendar Object
> >>
> >>  The Calendaring and Scheduling Core Object is a collection of
> >>  calendaring and scheduling information. Typically, this information
> >>  will consist of a single iCalendar object. However, multiple
> >>  iCalendar objects can be sequentially grouped together.
> >>
> Ah, bleep.  I knew I should've checked the spec.

Thanks Doug for noting this sooner than I could.  Ive been more than a 
little distracted w/our endgame and trying to juggle in CalConnect 3.

> (This'd be something to test for at CalConnect, BTW; I know I've written 

> at least one parser that assumed there was only one iCalendar object per 

> text/calendar, and I bet I'm not the only one.)

Hopefully the next one will be better then.  Im sure you are not alone 
given the sheer size of the RFCs but hopefully folks can change their 
engines to at least accomodate the data.

Since this is not a MUST/SHOULD/MAY/etc in the RFC (its just there) its 
not something that would normally be tested at a CalConnect (but perhaps 
we can try in the future).

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 00518B0B85256C2F_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">John wrote:</font>
<br><font size=2><tt>&gt; &gt;&gt;4.4 iCalendar Object<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &nbsp;The Calendaring and Scheduling Core Object is a collection
of<br>
&gt; &gt;&gt; &nbsp;calendaring and scheduling information. Typically,
this information<br>
&gt; &gt;&gt; &nbsp;will consist of a single iCalendar object. However,
multiple<br>
&gt; &gt;&gt; &nbsp;iCalendar objects can be sequentially grouped together.<br>
&gt; &gt;&gt;<br>
&gt; Ah, bleep. &nbsp;I knew I should've checked the spec.<br>
</tt></font>
<br><font size=2 face="sans-serif">Thanks Doug for noting this sooner than
I could. &nbsp;Ive been more than a little distracted w/our endgame and
trying to juggle in CalConnect 3.</font>
<br><font size=2 face="sans-serif"><br>
</font><font size=2><tt>&gt; (This'd be something to test for at CalConnect,
BTW; I know I've written <br>
&gt; at least one parser that assumed there was only one iCalendar object
per <br>
&gt; text/calendar, and I bet I'm not the only one.)</tt></font>
<br>
<br><font size=2 face="sans-serif">Hopefully the next one will be better
then. &nbsp;Im sure you are not alone given the sheer size of the RFCs
but hopefully folks can change their engines to at least accomodate the
data.</font>
<br>
<br><font size=2 face="sans-serif">Since this is not a MUST/SHOULD/MAY/etc
in the RFC (its just there) its not something that would normally be tested
at a CalConnect (but perhaps we can try in the future).</font>
<br><font size=2 face="sans-serif"><br>
Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 00518B0B85256C2F_=--


From owner-ietf-calendar@mail.imc.org  Mon Sep  9 11:20:52 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07009
	for <calsch-archive@lists.ietf.org>; Mon, 9 Sep 2002 11:20:52 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g89FBVe13909
	for ietf-calendar-bks; Mon, 9 Sep 2002 08:11:31 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g89FBTk13903
	for <ietf-calendar@imc.org>; Mon, 9 Sep 2002 08:11:29 -0700 (PDT)
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF5BD1DBF8.FEACEE1E-ON85256C2F.0052438E-85256C2F.0053792A@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Mon, 9 Sep 2002 11:11:27 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/09/2002 11:05:16 AM,
	Serialize complete at 09/09/2002 11:05:16 AM
Content-Type: multipart/alternative; boundary="=_alternative 0053792185256C2F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0053792185256C2F_=
Content-Type: text/plain; charset="US-ASCII"

Doug replied:
>If I do a 'get me the entire VAGENDA', which do I want:
> 
>    (a) One massive blob in a multipart/related MIME object.
>    or
>    (b) A massive amount of small blobs each in a single
>             MIME object.
>    or
>    (c) A mixture of (a) and (b) with multiple icalobjects
>        in each (b) of the same METHOD.

What you as a CUA want may/will be different than what the CS wants for 
assorted reasons.  The CS may find it easier to do any of the above for 
various reasons (ie: "Dump whats in the cache first and then go find 
individuals that are not aready sent", "Process what I can in a given 
amount of time, send it and then go back and repeat until done", "Start 
with the first match, process it and find the next one to continue with", 
etc.).

To make a CUA implementors life easier some may wish for 'lots of little 
bite size data' because its less for them to worry about (ie: parsing 
large blocks of data in a timely manner, making correct/incorrect 
assumptions about the format of the data stream to be returned when they 
initially designed their engine, etc).  However this makes the CS 
implementors life worse as it implicitly forces some CS designs on them 
that may not be suitable for them (ie: it degrades scalablilty or 
efficiency).

Given that CS performance/scalability is of greater interest to me I would 
say that (c) is probably the route to take.  If we are NOT clear in the 
draft then we will run into the same kinds of assumptions like John made 
in his parser regarding mulitple icalobjects.

>Before we can decide on the ANS vs RPY. 

Doesnt this depend on which case is involved?  For (a) it would be a RPY 
but for (c) it would be an ANS, no??  (Ive still not fully absorbed BEEP 
nuances.)

>                                          Are there any
> of the above we can eliminate as valid (outside of BEEP)?
> Are there more?

Dont think so and not that I can see.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0053792185256C2F_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Doug replied:</font>
<br><font size=2><tt>&gt;If I do a 'get me the entire VAGENDA', which do
I want:<br>
&gt; <br>
&gt; &nbsp; &nbsp;(a) One massive blob in a multipart/related MIME object.<br>
&gt; &nbsp; &nbsp;or<br>
&gt; &nbsp; &nbsp;(b) A massive amount of small blobs each in a single<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; MIME object.<br>
&gt; &nbsp; &nbsp;or<br>
&gt; &nbsp; &nbsp;(c) A mixture of (a) and (b) with multiple icalobjects<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;in each (b) of the same METHOD.<br>
</tt></font>
<br><font size=2 face="sans-serif">What you as a CUA want may/will be different
than what the CS wants for assorted reasons. &nbsp;The CS may find it easier
to do any of the above for various reasons (ie: &quot;Dump whats in the
cache first and then go find individuals that are not aready sent&quot;,
&quot;Process what I can in a given amount of time, send it and then go
back and repeat until done&quot;, &quot;Start with the first match, process
it and find the next one to continue with&quot;, etc.).</font>
<br>
<br><font size=2 face="sans-serif">To make a CUA implementors life easier
some may wish for 'lots of little bite size data' because its less for
them to worry about (ie: parsing large blocks of data in a timely manner,
making correct/incorrect assumptions about the format of the data stream
to be returned when they initially designed their engine, etc). &nbsp;However
this makes the CS implementors life worse as it implicitly forces some
CS designs on them that may not be suitable for them (ie: it degrades scalablilty
or efficiency).</font>
<br>
<br><font size=2 face="sans-serif">Given that CS performance/scalability
is of greater interest to me I would say that (c) is probably the route
to take. &nbsp;If we are NOT clear in the draft then we will run into the
same kinds of assumptions like John made in his parser regarding mulitple
icalobjects.</font>
<br><font size=2><tt><br>
&gt;Before we can decide on the ANS vs RPY. </tt></font>
<br>
<br><font size=2 face="sans-serif">Doesnt this depend on which case is
involved? &nbsp;For (a) it would be a RPY but for (c) it would be an ANS,
no?? &nbsp;(Ive still not fully absorbed BEEP nuances.)</font>
<br>
<br><font size=2><tt>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;Are there any<br>
&gt; of the above we can eliminate as valid (outside of BEEP)?<br>
&gt; Are there more?</tt></font>
<br>
<br><font size=2 face="sans-serif">Dont think so and not that I can see.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0053792185256C2F_=--


From owner-ietf-calendar@mail.imc.org  Mon Sep  9 12:02:01 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08449
	for <calsch-archive@lists.ietf.org>; Mon, 9 Sep 2002 12:02:00 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g89FpHh15331
	for ietf-calendar-bks; Mon, 9 Sep 2002 08:51:17 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g89FpFk15327
	for <ietf-calendar@imc.org>; Mon, 9 Sep 2002 08:51:16 -0700 (PDT)
To: John Stracke <jstracke@centivinc.com>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF8AE31CF1.DFF31E17-ON85256C2F.00541F0A-85256C2F.00571B88@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Mon, 9 Sep 2002 11:51:08 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/09/2002 11:45:02 AM,
	Serialize complete at 09/09/2002 11:45:02 AM
Content-Type: multipart/alternative; boundary="=_alternative 00571B8485256C2F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 00571B8485256C2F_=
Content-Type: text/plain; charset="US-ASCII"

John wrote:
> There isn't one.  But multipart/related has a single bodypart, the root, 

> which coordinates the others--as in the case of an HTML email message 
> which contains both the HTML page (the root) and the images it uses. 
>  Maybe you mean multipart/mixed?

Multipart/related may be the proper one given the definition of 
mulitpart/mixed in RFC 2387:

   The Multipart/Related content-type addresses the MIME representation
   of compound objects. 
[Snip, snip]
   Responsibility for the display or processing of a Multipart/Related's
   constituent entities rests with the application that handles the
   compound object.

The intended use of multipart/mixed is:

3.  Intended usage

   The Multipart/Related media type is intended for compound objects
   consisting of several inter-related body parts.  For a
   Multipart/Related object, proper display cannot be achieved by
   individually displaying the constituent body parts.  The content-type
   of the Multipart/Related object is specified by the type parameter.

which seems to be what we are trying to achieve here.  In this case we are 
trying to represent the VAGENDA by lots of smaller blobs of data.  WRT to 
the 'root' element, it is defined by:

3.2.  The Start Parameter

   The start parameter, if given, is the content-ID of the compound
   object's "root".  If not present the "root" is the first body part in
   the Multipart/Related entity.  The "root" is the element the
   applications processes first.

Unlike MHTML where we need to process the HTML before we can properly 
render the images in the right way, I dont think that it applys to 
iCalendar VAGENDAs since we dont need to have the data in a particular 
order to render it.  (So bascially we do not need a 'root' element but 
specifiying one does not seem to be any real issue either.)

If you check RFC 24046 you will find in Section 5.1.3 Mixed Subtype the 
following definition for its use:

   The "mixed" subtype of "multipart" is intended for use when the body
   parts are independent and need to be bundled in a particular order.

In the VAGENDA case I dont think we have a need for data in a particular 
order.  It could be argued that the returned entries are 'independent' in 
the calendar and thus meet that criteria but if they are being used to 
rebuild a larger VAGNEDA then I dont think thats true any more.

So it looks on my first pass as if multipart/related is the proper MIME 
type to use over multipart/mixed.

> >The one multipart/related huge blob can arrive now - per iCal.
> >Correct?
> >
> Uh...no.  The term "multipart/related" does not appear in RFC-2445.  Nor 

> is it a requirement for basic MIME processing.

There is no explicit mention of multipart at all in 2445 but its there in 
stuff like ATTACH, ALTREP, etc.  As for the last bit, actually its 
addressed in RFC 2049 (and partly in RFC 2046) which is part of the 'base' 
MIME set.  If you look at RFC 2049 you will see:

   A mail user agent that is MIME-conformant MUST:
[Snip]
    (6)   Explicitly handle the following media type values, to
          at least the following extents:
[Snip, snip]
          Multipart:

            -- Recognize the mixed subtype.  Display all relevant
            information on the message level and the body part
            header level and then display or offer to display
            each of the body parts individually.

            -- Recognize the "alternative" subtype, and avoid
            showing the user redundant parts of
            multipart/alternative mail.

            -- Recognize the "multipart/digest" subtype,
            specifically using "message/rfc822" rather than
            "text/plain" as the default media type for body parts
            inside "multipart/digest" entities.

            -- Treat any unrecognized subtypes as if they were
            "mixed".

so no there is no explicit multipart/related compliance mandated (since 
its not part of the base MIME RFCs) but there is a mandate for dealing 
with 'unknown' subtypes (and you could call 'related' unknown if you have 
an old engine that is pre ~1995 when multipart/related was first specd). 
However we are now coding a new generation of client that should be able 
to deal with multipart/related just fine.  Unless there is someone who 
coded up a BEEP/CAP CUA pre-mulitpart/related I dont think that 
mulitpart/related 'conformance' is a real issue or reason to pick an 
unsuitable MIME subtype.

And I do believe that Doug was correct in his question...

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 00571B8485256C2F_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>John wrote:<br>
&gt; There isn't one. &nbsp;But multipart/related has a single bodypart,
the root, <br>
&gt; which coordinates the others--as in the case of an HTML email message
<br>
&gt; which contains both the HTML page (the root) and the images it uses.
<br>
&gt; &nbsp;Maybe you mean multipart/mixed?<br>
</tt></font>
<br><font size=2 face="sans-serif">Multipart/related may be the proper
one given the definition of mulitpart/mixed in RFC 2387:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;The Multipart/Related content-type addresses
the MIME representation<br>
 &nbsp; of compound objects. </tt></font>
<br><font size=2><tt>[Snip, snip]</tt></font>
<br><font size=2><tt>&nbsp; &nbsp;Responsibility for the display or processing
of a Multipart/Related's<br>
 &nbsp; constituent entities rests with the application that handles the<br>
 &nbsp; compound object.<br>
</tt></font>
<br><font size=2 face="sans-serif">The intended use of multipart/mixed
is:</font>
<br>
<br><font size=2><tt>3. &nbsp;Intended usage<br>
<br>
 &nbsp; The Multipart/Related media type is intended for compound objects<br>
 &nbsp; consisting of several inter-related body parts. &nbsp;For a<br>
 &nbsp; Multipart/Related object, proper display cannot be achieved by<br>
 &nbsp; individually displaying the constituent body parts. &nbsp;The content-type<br>
 &nbsp; of the Multipart/Related object is specified by the type parameter.<br>
</tt></font>
<br><font size=2 face="sans-serif">which seems to be what we are trying
to achieve here. &nbsp;In this case we are trying to represent the VAGENDA
by lots of smaller blobs of data. &nbsp;WRT to the 'root' element, it is
defined by:</font>
<br>
<br><font size=2><tt>3.2. &nbsp;The Start Parameter<br>
<br>
 &nbsp; The start parameter, if given, is the content-ID of the compound<br>
 &nbsp; object's &quot;root&quot;. &nbsp;If not present the &quot;root&quot;
is the first body part in<br>
 &nbsp; the Multipart/Related entity. &nbsp;The &quot;root&quot; is the
element the<br>
 &nbsp; applications processes first.<br>
</tt></font>
<br><font size=2 face="sans-serif">Unlike MHTML where we need to process
the HTML before we can properly render the images in the right way, I dont
think that it applys to iCalendar VAGENDAs since we dont need to have the
data in a particular order to render it. &nbsp;(So bascially we do not
need a 'root' element but specifiying one does not seem to be any real
issue either.)</font>
<br>
<br><font size=2 face="sans-serif">If you check RFC 24046 you will find
in Section 5.1.3 Mixed Subtype the following definition for its use:<br>
<br>
</font><font size=2><tt> &nbsp; The &quot;mixed&quot; subtype of &quot;multipart&quot;
is intended for use when the body<br>
 &nbsp; parts are independent and need to be bundled in a particular order.</tt></font>
<br>
<br><font size=2 face="sans-serif">In the VAGENDA case I dont think we
have a need for data in a particular order. &nbsp;It could be argued that
the returned entries are 'independent' in the calendar and thus meet that
criteria but if they are being used to rebuild a larger VAGNEDA then I
dont think thats true any more.</font>
<br>
<br><font size=2 face="sans-serif">So it looks on my first pass as if multipart/related
is the proper MIME type to use over multipart/mixed.</font>
<br><font size=2><tt><br>
&gt; &gt;The one multipart/related huge blob can arrive now - per iCal.<br>
&gt; &gt;Correct?<br>
&gt; &gt;<br>
&gt; Uh...no. &nbsp;The term &quot;multipart/related&quot; does not appear
in RFC-2445. &nbsp;Nor <br>
&gt; is it a requirement for basic MIME processing.<br>
</tt></font>
<br><font size=2 face="sans-serif">There is no explicit mention of multipart
at all in 2445 but its there in stuff like ATTACH, ALTREP, etc. &nbsp;As
for the last bit, actually its addressed in RFC 2049 (and partly in RFC
2046) which is part of the 'base' MIME set. &nbsp;If you look at RFC 2049
you will see:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;A mail user agent that is MIME-conformant
MUST:<br>
[Snip]</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; (6) &nbsp; Explicitly handle the following
media type values, to<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;at least the following extents:<br>
[Snip, snip]</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Multipart:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;-- Recognize the mixed subtype.
&nbsp;Display all relevant<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;information on the message level
and the body part<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;header level and then display
or offer to display<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;each of the body parts individually.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;-- Recognize the &quot;alternative&quot;
subtype, and avoid<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;showing the user redundant parts
of<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;multipart/alternative mail.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;-- Recognize the &quot;multipart/digest&quot;
subtype,<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;specifically using &quot;message/rfc822&quot;
rather than<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;text/plain&quot; as the
default media type for body parts<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;inside &quot;multipart/digest&quot;
entities.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;-- Treat any unrecognized subtypes
as if they were<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;mixed&quot;.<br>
</tt></font>
<br><font size=2 face="sans-serif">so no there is no explicit multipart/related
compliance mandated (since its not part of the base MIME RFCs) but there
is a mandate for dealing with 'unknown' subtypes (and you could call 'related'
unknown if you have an old engine that is pre ~1995 when multipart/related
was first specd). &nbsp;However we are now coding a new generation of client
that should be able to deal with multipart/related just fine. &nbsp;Unless
there is someone who coded up a BEEP/CAP CUA pre-mulitpart/related I dont
think that mulitpart/related 'conformance' is a real issue or reason to
pick an unsuitable MIME subtype.</font>
<br>
<br><font size=2 face="sans-serif">And I do believe that Doug was correct
in his question...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
--=_alternative 00571B8485256C2F_=--


From owner-ietf-calendar@mail.imc.org  Mon Sep  9 12:30:07 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09424
	for <calsch-archive@lists.ietf.org>; Mon, 9 Sep 2002 12:30:06 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g89GMXf16043
	for ietf-calendar-bks; Mon, 9 Sep 2002 09:22:33 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g89GMUk16039
	for <ietf-calendar@imc.org>; Mon, 9 Sep 2002 09:22:31 -0700 (PDT)
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Mon, 9 Sep 2002 12:22:27 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/09/2002 12:16:18 PM,
	Serialize complete at 09/09/2002 12:16:18 PM
Content-Type: multipart/alternative; boundary="=_alternative 0059F96685256C2F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0059F96685256C2F_=
Content-Type: text/plain; charset="US-ASCII"

Doug wrote:
> > There isn't one.  But multipart/related has a single bodypart, the 
root, 
> > which coordinates the others--as in the case of an HTML email message 
> > which contains both the HTML page (the root) and the images it uses. 
> > Maybe you mean multipart/mixed?
> 
> It has been a while so maybe it is multipart/mixed that I mean.

As I just noted in a reponse to John I think that multipart/related is 
probably the way to go and that we dont really care what the 'root' 
element is (it will default to the 1st element in the stream if we dont 
expressly declare one).  Given in RFC 2046 multipart/mixed is defined by:

5.1.3.  Mixed Subtype

   The "mixed" subtype of "multipart" is intended for use when the body
   parts are independent and need to be bundled in a particular order.

I dont think that it really applys (at least the 'need to be bundled in a 
particular order' bit).  Since RFC 2387 clearly defines the role of 
multipart/related as:

   The Multipart/Related content-type addresses the MIME representation
   of compound objects.  The object is categorized by a "type"
   parameter.  Additional parameters are provided to indicate a specific
   starting body part or root and auxiliary information which may be
   required when unpacking or processing the object.

Id say that we should use multipart/related over multipart/mixed.  We are 
after all representing a VAGNEDA which is a compound object built up of 
several VEVENTs, VTODOs, VJOURNALs, VTIMEZONEs, etc.

> Is multipart/related when you have the first part that can
> contain CID's or MID's?

Actually any MIME part can contain a MID (although in an 
application/octet-stream its probably not the same as in a text/html) and 
any body part can contain a CID if its inside a multipart message (ie: 
MHTML is text/html and it contains the CID in it for the embeded message 
thats in a separate image/png body part).

> So multipart/<something> must be valid.

Correct.

> I remember this list talking about multipart/<whatever> pre CAP
> and just after the first cal-connect. Some implementations
> used it, others disallowed it. I think the consensus was that
> we can not mandate it, and can not disallow it. It was a MAY.
> 
> It is not that hard to implement multilpart/<whatever>.

I find references to this as far back as April 2000 under the thread " 
CALSCH Action Items - - Error".  Back then we all seemed to agree on this.

I agree, that building a multipart savy UA is not nuclear science any more 
(unless you've never read any MIME RFCs and you take the Microsoft 
Entourage approach).

I did find a note from Frank along this vein that is relevant so Im 
partally including it below to save you archive digging time:

iCalendar, RFC 2445, just defines a MIME type. This is NOT the place to 
specify how you encapsulate the MIME type. We just define here a 
text/calendar MIME content type. 
It is iMIP, RFC 2447, that defines how you send an iCalendar object in 
email. That email could be as a singleton, text/calendar MIME object or as 
a multipart object, such as multipart/mixed or such. This is where the 
requirement is absent. I suggest that we all go back and read the RFC 2447 
spec.

In any case I think we all seem to agree that multipart support is 
necessary (if not implicitly mandated), we just need to pick the proper 
subtype based on their definitions and get on to the real work.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

..
--=_alternative 0059F96685256C2F_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug wrote:<br>
&gt; &gt; There isn't one. &nbsp;But multipart/related has a single bodypart,
the root, <br>
&gt; &gt; which coordinates the others--as in the case of an HTML email
message <br>
&gt; &gt; which contains both the HTML page (the root) and the images it
uses. <br>
&gt; &gt; Maybe you mean multipart/mixed?<br>
&gt; <br>
&gt; It has been a while so maybe it is multipart/mixed that I mean.<br>
</tt></font>
<br><font size=2 face="sans-serif">As I just noted in a reponse to John
I think that multipart/related is probably the way to go and that we dont
really care what the 'root' element is (it will default to the 1st element
in the stream if we dont expressly declare one). &nbsp;Given in RFC 2046
multipart/mixed is defined by:</font>
<br>
<br><font size=2><tt>5.1.3. &nbsp;Mixed Subtype<br>
<br>
 &nbsp; The &quot;mixed&quot; subtype of &quot;multipart&quot; is intended
for use when the body<br>
 &nbsp; parts are independent and need to be bundled in a particular order.</tt></font>
<br>
<br><font size=2 face="sans-serif">I dont think that it really applys (at
least the 'need to be bundled in a particular order' bit). &nbsp;Since
RFC 2387 clearly defines the role of multipart/related as:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;The Multipart/Related content-type addresses
the MIME representation<br>
 &nbsp; of compound objects. &nbsp;The object is categorized by a &quot;type&quot;<br>
 &nbsp; parameter. &nbsp;Additional parameters are provided to indicate
a specific<br>
 &nbsp; starting body part or root and auxiliary information which may
be<br>
 &nbsp; required when unpacking or processing the object.</tt></font>
<br>
<br><font size=2 face="sans-serif">Id say that we should use multipart/related
over multipart/mixed. &nbsp;We are after all representing a VAGNEDA which
is a compound object built up of several VEVENTs, VTODOs, VJOURNALs, VTIMEZONEs,
etc.</font>
<br><font size=2><tt><br>
&gt; Is multipart/related when you have the first part that can<br>
&gt; contain CID's or MID's?<br>
</tt></font>
<br><font size=2 face="sans-serif">Actually any MIME part can contain a
MID (although in an application/octet-stream its probably not the same
as in a text/html) and any body part can contain a CID if its inside a
multipart message (ie: MHTML is text/html and it contains the CID in it
for the embeded message thats in a separate image/png body part).</font>
<br><font size=2 face="sans-serif"><br>
</font><font size=2><tt>&gt; So multipart/&lt;something&gt; must be valid.<br>
</tt></font>
<br><font size=2 face="sans-serif">Correct.<br>
<br>
</font><font size=2><tt>&gt; I remember this list talking about multipart/&lt;whatever&gt;
pre CAP<br>
&gt; and just after the first cal-connect. Some implementations<br>
&gt; used it, others disallowed it. I think the consensus was that<br>
&gt; we can not mandate it, and can not disallow it. It was a MAY.<br>
&gt; <br>
&gt; It is not that hard to implement multilpart/&lt;whatever&gt;.<br>
</tt></font>
<br><font size=2 face="sans-serif">I find references to this as far back
as April 2000 under the thread &quot; CALSCH Action Items - - Error&quot;.
&nbsp;Back then we all seemed to agree on this.</font>
<br>
<br><font size=2 face="sans-serif">I agree, that building a multipart savy
UA is not nuclear science any more (unless you've never read any MIME RFCs
and you take the Microsoft Entourage approach).</font>
<br>
<br><font size=2 face="sans-serif">I did find a note from Frank along this
vein that is relevant so Im partally including it below to save you archive
digging time:</font>
<br>
<br><font size=2><tt>iCalendar, RFC 2445, just defines a MIME type. This
is NOT the place to specify how you encapsulate the MIME type. We just
define here a text/calendar MIME content type. </tt></font>
<br><font size=2><tt>It is iMIP, RFC 2447, that defines how you send an
iCalendar object in email. That email could be as a singleton, text/calendar
MIME object or as a multipart object, such as multipart/mixed or such.
This is where the requirement is absent. I suggest that we all go back
and read the RFC 2447 spec.</tt></font>
<br>
<br><font size=2 face="sans-serif">In any case I think we all seem to agree
that multipart support is necessary (if not implicitly mandated), we just
need to pick the proper subtype based on their definitions and get on to
the real work.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
<br><font size=2 face="sans-serif">..</font>
--=_alternative 0059F96685256C2F_=--


From owner-ietf-calendar@mail.imc.org  Mon Sep  9 12:31:21 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09523
	for <calsch-archive@lists.ietf.org>; Mon, 9 Sep 2002 12:31:20 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g89GOgi16121
	for ietf-calendar-bks; Mon, 9 Sep 2002 09:24:42 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g89GOfk16116
	for <ietf-calendar@imc.org>; Mon, 9 Sep 2002 09:24:41 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002090912332328307
 for <ietf-calendar@imc.org>; Mon, 09 Sep 2002 12:33:23 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 9 Sep 2002 12:23:00 -0400
Message-ID: <3D7CCAE4.8020104@centivinc.com>
Date: Mon, 09 Sep 2002 12:23:00 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF8AE31CF1.DFF31E17-ON85256C2F.00541F0A-85256C2F.00571B88@iris.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Sep 2002 16:23:00.0306 (UTC) FILETIME=[2A143B20:01C2581D]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

> In this case we are trying to represent the VAGENDA by lots of smaller 
> blobs of data.

I'm not sure that's true.  We're trying to represent the answer to a 
query such as "what objects are in the VAGENDA?".  That answer is not 
the VAGENDA itself.

> If you look at RFC 2049 you will see:
>
>    A mail user agent that is MIME-conformant MUST:

I'll say it again: a CAP CUA is not necessarily an MUA.  This means that 
RFC-2049 does not apply to CAP.  It applies to iMIP only because iMIP 
runs over email, and so an iMIP implementation is necessarily an MUA.

-- 
/============================================================\
|John Stracke      |jstracke@centivinc.com                   |
|Principal Engineer|http://www.centivinc.com                 |
|Centiv            |My opinions are my own.                  |
|============================================================|
|"I lost an 7-foot boa constrictor once in our house." --Gary|
|Larson on his youth                                         |
\============================================================/




From owner-ietf-calendar@mail.imc.org  Mon Sep  9 13:02:39 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10207
	for <calsch-archive@lists.ietf.org>; Mon, 9 Sep 2002 13:02:38 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g89Gsov16961
	for ietf-calendar-bks; Mon, 9 Sep 2002 09:54:50 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g89Gsmk16955
	for <ietf-calendar@imc.org>; Mon, 9 Sep 2002 09:54:48 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002090913033116762
 for <ietf-calendar@imc.org>; Mon, 09 Sep 2002 13:03:31 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 9 Sep 2002 12:53:07 -0400
Message-ID: <3D7CD1F3.1060201@centivinc.com>
Date: Mon, 09 Sep 2002 12:53:07 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Sep 2002 16:53:07.0301 (UTC) FILETIME=[5F21C950:01C25821]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

> In any case I think we all seem to agree that multipart support is 
> necessary (if not implicitly mandated),

No, we do not.  The thread you cite was an related to iMIP, which 
inherits MUA-based requirements from MIME.  It does *not* mean that 
every iCalendar-based application must support multipart.

-- 
/============================================================\
|John Stracke      |jstracke@centivinc.com                   |
|Principal Engineer|http://www.centivinc.com                 |
|Centiv            |My opinions are my own.                  |
|============================================================|
|"I lost an 7-foot boa constrictor once in our house." --Gary|
|Larson on his youth                                         |
\============================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 05:45:53 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08326
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 05:45:52 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8A9cTe08143
	for ietf-calendar-bks; Tue, 10 Sep 2002 02:38:29 -0700 (PDT)
Received: from mail.samsungcontact.com (host195-89-159-51.uk.regusnet.com [195.89.159.51])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8A9cRk08139
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 02:38:28 -0700 (PDT)
Received: from mail.samsungcontact.com (root@localhost)
	by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g8A9c4U00493;
	Tue, 10 Sep 2002 10:38:04 +0100
Received: from samsungcontact.com (host195-89-159-62.uk.regusnet.com 195.89.159.62)
        by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0)
        via ESMTP; Tue, 10 Sep 2002 10:38:05 +0100 (BST)
Message-ID: <3D7DBD7C.7070409@samsungcontact.com>
Date: Tue, 10 Sep 2002 10:38:04 +0100
From: Mark Davidson <markd@samsungcontact.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Stracke <jstracke@centivinc.com>
CC: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


John Stracke wrote:
> 
> Bruce_Kahn@notesdev.ibm.com wrote:
> 
>> In any case I think we all seem to agree that multipart support is 
>> necessary (if not implicitly mandated),
> 
> 
> No, we do not.  The thread you cite was an related to iMIP, which 
> inherits MUA-based requirements from MIME.  It does *not* mean that 
> every iCalendar-based application must support multipart.
> 

I agree with John. I see no reason why a CUA needs to use multipart anything when talking to a CAP 
server. It just adds another wrapping of the data that adds nothing and making parsing harder.

Mark Davidson



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 06:34:00 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09100
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 06:33:59 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AAL6t10853
	for ietf-calendar-bks; Tue, 10 Sep 2002 03:21:06 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AAL5k10846
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 03:21:05 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 78A751552C; Tue, 10 Sep 2002 12:21:04 +0200 (CEST)
Date: Tue, 10 Sep 2002 12:21:04 +0200
From: Andrea Campi <a.campi@inet.it>
To: Mark Davidson <markd@samsungcontact.com>
Cc: John Stracke <jstracke@centivinc.com>, ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
Message-ID: <20020910102104.GD83146@inet.it>
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com> <3D7DBD7C.7070409@samsungcontact.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D7DBD7C.7070409@samsungcontact.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Tue, Sep 10, 2002 at 10:38:04AM +0100, Mark Davidson wrote:
> >>In any case I think we all seem to agree that multipart support is 
> >>necessary (if not implicitly mandated),
> >
> >No, we do not.  The thread you cite was an related to iMIP, which 
> >inherits MUA-based requirements from MIME.  It does *not* mean that 
> >every iCalendar-based application must support multipart.
> 
> I agree with John. I see no reason why a CUA needs to use multipart 
> anything when talking to a CAP server. It just adds another wrapping of the 
> data that adds nothing and making parsing harder.
> 

I agree that we don't HAVE to support multipart. Now, if there was
a compelling reason, or a real advantage, then we can decided
whether to make it mandatory or optional.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 10:58:12 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16606
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 10:58:11 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AEbIc29237
	for ietf-calendar-bks; Tue, 10 Sep 2002 07:37:18 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AEbFk29231
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 07:37:16 -0700 (PDT)
In-Reply-To: <3D7DBD7C.7070409@samsungcontact.com>
To: Mark Davidson <markd@samsungcontact.com>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OFDC2A8C6C.91A5F601-ON85256C30.004FD41E-85256C30.0050519D@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 10:37:13 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 10:30:54 AM,
	Serialize complete at 09/10/2002 10:30:54 AM
Content-Type: multipart/alternative; boundary="=_alternative 0050519685256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0050519685256C30_=
Content-Type: text/plain; charset="US-ASCII"

Mark  wrote on 09/10/2002 05:38:04 AM:
> > No, we do not.  The thread you cite was an related to iMIP, which 
> > inherits MUA-based requirements from MIME.  It does *not* mean that 
> > every iCalendar-based application must support multipart.
> > 
> 
> I agree with John. I see no reason why a CUA needs to use multipart 
> anything when talking to a CAP 
> server. It just adds another wrapping of the data that adds nothing 
> and making parsing harder.

Then how do you expect the ATTACHments and other related kinds of data is 
going to get to the server?  Does the server magically regenerate the 
richer HTML rendering of DESCRIPTION from thin air or by some heuristic? 
That data has to get to the server somehow.  I have yet to read any 
commands or other ways for the CUA to get that kind of data to the CS. Did 
I miss it?

If not then the CS and CUAs are going to need to be multipart savy. 

Also, you need to be clearer about which parser you are talking about too: 
BEEP, iCalendar, CAP or some mix thereof.  The BEEP engine does not need 
to be parsing the multipart data and any iCalendar parser you have has to 
be at least a little bit savy (to handle ALTREPs and ATTACHments).  I 
suspect you meant the CAP server engine that has to 'unbundle' the 
multipart and feed just the iCalendar to the iCalendar engine but I dont 
want to make any assumptions.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...


--=_alternative 0050519685256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Mark &nbsp;wrote on 09/10/2002 05:38:04 AM:<br>
&gt; &gt; No, we do not. &nbsp;The thread you cite was an related to iMIP,
which <br>
&gt; &gt; inherits MUA-based requirements from MIME. &nbsp;It does *not*
mean that <br>
&gt; &gt; every iCalendar-based application must support multipart.<br>
&gt; &gt; <br>
&gt; <br>
&gt; I agree with John. I see no reason why a CUA needs to use multipart
<br>
&gt; anything when talking to a CAP <br>
&gt; server. It just adds another wrapping of the data that adds nothing
<br>
&gt; and making parsing harder.<br>
</tt></font>
<br><font size=2 face="sans-serif">Then how do you expect the ATTACHments
and other related kinds of data is going to get to the server? &nbsp;Does
the server magically regenerate the richer HTML rendering of DESCRIPTION
from thin air or by some heuristic? &nbsp;That data has to get to the server
somehow. &nbsp;I have yet to read any commands or other ways for the CUA
to get that kind of data to the CS. &nbsp;Did I miss it?</font>
<br>
<br><font size=2 face="sans-serif">If not then the CS and CUAs are going
to need to be multipart savy. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Also, you need to be clearer about which
parser you are talking about too: BEEP, iCalendar, CAP or some mix thereof.
&nbsp;The BEEP engine does not need to be parsing the multipart data and
any iCalendar parser you have has to be at least a little bit savy (to
handle ALTREPs and ATTACHments). &nbsp;I suspect you meant the CAP server
engine that has to 'unbundle' the multipart and feed just the iCalendar
to the iCalendar engine but I dont want to make any assumptions.<br>
</font>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
<br>
--=_alternative 0050519685256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:05:12 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16849
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:05:12 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AEw7h29912
	for ietf-calendar-bks; Tue, 10 Sep 2002 07:58:07 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AEw5k29908
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 07:58:06 -0700 (PDT)
In-Reply-To: <20020910102104.GD83146@inet.it>
To: Andrea Campi <a.campi@inet.it>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 10:58:04 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 10:51:44 AM,
	Serialize complete at 09/10/2002 10:51:44 AM
Content-Type: multipart/alternative; boundary="=_alternative 00523A4285256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 00523A4285256C30_=
Content-Type: text/plain; charset="US-ASCII"

Andrea wrote on 09/10/2002 06:21:04 AM:
> I agree that we don't HAVE to support multipart. Now, if there was
> a compelling reason, or a real advantage, then we can decided
> whether to make it mandatory or optional.

Part of the confusion as to _if_ we need multipart comes from Johns 
mention of iMIP (per my citation).  While the citation came from an iMIP 
thread it does apply to CAP indirectly.  Since CAP essentially 
encapsulates iRIP (the 'real time' binding of iTIP) it needs to have the 
same abilities we have already covered and agreed on.  Ill try to take a 
better approach to get WG clarification and agreement (if not more lively 
discussion).

I will ask the same question again so that I hear the answer from those 
that think multipart support is NOT necessary in CAP: How do you expect to 
deal with ATTACHments and richer content renderings (ie: ALTREPs) if you 
do NOT have multipart support in the protocol/engine?  (Will they 
magically appear in my local CUA or will it have to download them using 
some undocumented CAP command or OOB mechanism??)

Im not claiming that me must mandate multipart support (I wont force you 
to support common iCalendar/iTIP features like ATTACHments and HTML but my 
users will!). 

Im claiming that w/o clearly defining how multipart support is to be used 
and supported in CAP then you're wasting everyones time now and going to 
cause untold hassles in the future (if not outright rejection of it). 

Look at the issues we have now in iMIP w/multipart support.  Some CUAs 
don't support it at all (ie: no ATTACHments, etc)  Some CUAs take one 
approach that may be contrary to the multipart semantics.  Some CUAs take 
a 'hybrid' approach to multipart in order to be 'richer' and to support 
workflow w/the other CUAs.  Its a big hodgepodge that makes interop 
testing less that seamless.  As a big user of C&S I really like seamless. 
Maybe its just me and most users want to have lots of limitations or hoops 
to jump thru....  Do we want to go thru this exact same morass with CAP as 
CAP clients start to develop??

After all, if I can send a simple iMIP meeting invite w/an attached agenda 
or related document NOW, why cant I use my "newer and improved" CAP CUA to 
read it from the newer CAP server when I could do it using POP3 or IMAP 
now?

As for compelling reason:  Removing features that users have now is NOT a 
step forward, its a total regression of functionality that I know people 
will balk at loosing.  Would you 'upgrade' to a newer client product if 
you knew you were losing features you already have and use?

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 00523A4285256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Andrea wrote on 09/10/2002 06:21:04 AM:<br>
&gt; I agree that we don't HAVE to support multipart. Now, if there was<br>
&gt; a compelling reason, or a real advantage, then we can decided<br>
&gt; whether to make it mandatory or optional.<br>
</tt></font>
<br><font size=2 face="sans-serif">Part of the confusion as to _if_ we
need multipart comes from Johns mention of iMIP (per my citation). &nbsp;While
the citation came from an iMIP thread it does apply to CAP indirectly.
&nbsp;Since CAP essentially encapsulates iRIP (the 'real time' binding
of iTIP) it needs to have the same abilities we have already covered and
agreed on. &nbsp;Ill try to take a better approach to get WG clarification
and agreement (if not more lively discussion).</font>
<br>
<br><font size=2 face="sans-serif">I will ask the same question again so
that I hear the answer from those that think multipart support is NOT necessary
in CAP: How do you expect to deal with ATTACHments and richer content renderings
(ie: ALTREPs) if you do NOT have multipart support in the protocol/engine?
&nbsp;(Will they magically appear in my local CUA or will it have to download
them using some undocumented CAP command or OOB mechanism??)</font>
<br>
<br><font size=2 face="sans-serif">Im not claiming that me must mandate
multipart support (I wont force you to support common iCalendar/iTIP features
like ATTACHments and HTML but my users will!). &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Im claiming that w/o clearly defining
how multipart support is to be used and supported in CAP then you're wasting
everyones time now and going to cause untold hassles in the future (if
not outright rejection of it). &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Look at the issues we have now in iMIP
w/multipart support. &nbsp;Some CUAs don't support it at all (ie: no ATTACHments,
etc) &nbsp;Some CUAs take one approach that may be contrary to the multipart
semantics. &nbsp;Some CUAs take a 'hybrid' approach to multipart in order
to be 'richer' and to support workflow w/the other CUAs. &nbsp;Its a big
hodgepodge that makes interop testing less that seamless. &nbsp;As a big
user of C&amp;S I really like seamless. &nbsp;Maybe its just me and most
users want to have lots of limitations or hoops to jump thru.... &nbsp;Do
we want to go thru this exact same morass with CAP as CAP clients start
to develop??</font>
<br>
<br><font size=2 face="sans-serif">After all, if I can send a simple iMIP
meeting invite w/an attached agenda or related document NOW, why cant I
use my &quot;newer and improved&quot; CAP CUA to read it from the newer
CAP server when I could do it using POP3 or IMAP now?</font>
<br>
<br><font size=2 face="sans-serif">As for compelling reason: &nbsp;Removing
features that users have now is NOT a step forward, its a total regression
of functionality that I know people will balk at loosing. &nbsp;Would you
'upgrade' to a newer client product if you knew you were losing features
you already have and use?</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 00523A4285256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:19:22 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17250
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:19:21 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFEQI00729
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:14:26 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFEPk00723
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:14:25 -0700 (PDT)
To: John Stracke <jstracke@centivinc.com>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF9ABC3D0F.ECA063FC-ON85256C30.0052A02D-85256C30.0053B87D@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 11:14:23 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 11:08:03 AM,
	Serialize complete at 09/10/2002 11:08:03 AM
Content-Type: multipart/alternative; boundary="=_alternative 0053B87985256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0053B87985256C30_=
Content-Type: text/plain; charset="US-ASCII"

John wrote:
> > In this case we are trying to represent the VAGENDA by lots of smaller 

> > blobs of data.
> 
> I'm not sure that's true.  We're trying to represent the answer to a 
> query such as "what objects are in the VAGENDA?".  That answer is not 
> the VAGENDA itself.

"Represent the VAGENDA by lots of smaller blobs of data" = "Represent the 
answer to the query such as 'what objects are in the VAGENDA?''  My phrase 
"represent the VAGENDA" was meant to be the same as your "What object are 
in the VAGENDA", I just didnt phrase it that way.  There are multiple 
objects in the VAGENDA is the point (I was not trying to factor in the 
properties of the VAGENDA when I used that phrase.)  Ill try to be even 
more precise in the future. 

However the example still stands: I have mutliple objects that make up the 
VAGENDA (or are contained by the VAGENDA if you prefer) and they are 
representable by smaller blobs of data.

> > If you look at RFC 2049 you will see:
> >
> >    A mail user agent that is MIME-conformant MUST:
> 
> I'll say it again: a CAP CUA is not necessarily an MUA.  This means that 

> RFC-2049 does not apply to CAP.  It applies to iMIP only because iMIP 
> runs over email, and so an iMIP implementation is necessarily an MUA.

Dont try to split hairs here!  Using that logic I could claim that my HTTP 
server and browsers dont have to be MIME complaint too just because the 
MIME RFCs use the term "A mail user agent" too!  That wont work though...

Since we are using MIME as our encoding framework we need to adhere to its 
rules for conformance.  As such CAP does not get any special "get out of 
MIME conformance free" card.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0053B87985256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>John wrote:<br>
&gt; &gt; In this case we are trying to represent the VAGENDA by lots of
smaller <br>
&gt; &gt; blobs of data.<br>
&gt; <br>
&gt; I'm not sure that's true. &nbsp;We're trying to represent the answer
to a <br>
&gt; query such as &quot;what objects are in the VAGENDA?&quot;. &nbsp;That
answer is not <br>
&gt; the VAGENDA itself.<br>
</tt></font>
<br><font size=2><tt>&quot;Represent the VAGENDA by lots of smaller blobs
of data&quot; = &quot;Represent the answer to the query such as 'what objects
are in the VAGENDA?''</tt></font><font size=2 face="sans-serif"> &nbsp;My
phrase &quot;represent the VAGENDA&quot; was meant to be the same as your
&quot;What object are in the VAGENDA&quot;, I just didnt phrase it that
way. &nbsp;There are multiple objects in the VAGENDA is the point (I was
not trying to factor in the properties of the VAGENDA when I used that
phrase.) &nbsp;Ill try to be even more precise in the future. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">However the example still stands: I
have mutliple objects that make up the VAGENDA (or are contained by the
VAGENDA if you prefer) and they are representable by smaller blobs of data.</font>
<br><font size=2><tt><br>
&gt; &gt; If you look at RFC 2049 you will see:<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp;A mail user agent that is MIME-conformant MUST:<br>
&gt; <br>
&gt; I'll say it again: a CAP CUA is not necessarily an MUA. &nbsp;This
means that <br>
&gt; RFC-2049 does not apply to CAP. &nbsp;It applies to iMIP only because
iMIP <br>
&gt; runs over email, and so an iMIP implementation is necessarily an MUA.<br>
</tt></font>
<br><font size=2 face="sans-serif">Dont try to split hairs here! &nbsp;Using
that logic I could claim that my HTTP server and browsers dont have to
be MIME complaint too just because the MIME RFCs use the term &quot;A mail
user agent&quot; too! &nbsp;That wont work though...</font>
<br>
<br><font size=2 face="sans-serif">Since we are using MIME as our encoding
framework we need to adhere to its rules for conformance. &nbsp;As such
CAP does not get any special &quot;get out of MIME conformance free&quot;
card.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
--=_alternative 0053B87985256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:35:05 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17789
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:35:05 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFRme01706
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:27:48 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFRlk01699
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:27:47 -0700 (PDT)
To: John Stracke <jstracke@centivinc.com>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OFE9994917.ABBC0BBA-ON85256C30.0053D036-85256C30.0054F1E8@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 11:27:45 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 11:21:25 AM,
	Serialize complete at 09/10/2002 11:21:25 AM
Content-Type: multipart/alternative; boundary="=_alternative 0054F1E385256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0054F1E385256C30_=
Content-Type: text/plain; charset="US-ASCII"

John wrote:
> No, we do not.

Weren't you arguing multipart/mixed vs multipart/related w/Doug just a few 
postings back??  They appeared to be that you agreed that mulitpart was in 
order, just you didnt necessarily agree of the subtype.  Was I wrong in 
reading _this_ thread so far??

>                The thread you cite was an related to iMIP, which 
> inherits MUA-based requirements from MIME.  It does *not* mean that 
> every iCalendar-based application must support multipart.

I did not mean to add iMIP to this discussion since its already baked and 
in the bag.  I was merely trying to show that we discussed the entire idea 
of multipart support a long time ago and we agreed then that it was 
useful/necessary.  The intent was/is to show we've already covered this so 
why are we covering it again?? 

Not every iCalendar application supports multipart (check CalConnect 
results yourself).  Due to this that means some apps do not easily work 
with other iCalendar apps unless extra steps are taken on someones part. 

Ill let the WG thrash over "do we want to have multipart in CAP" as long 
as they like since Ive alrady expressed my views on it. 

I will keep advocating that in CAP we must be much much more precise in 
specifying _how_ multipart is to be supported since CUAs already support 
multipart in iTIP you'd have to be foolish to regress it but you'd be wise 
to more precisely codify it that it was in iTIP.  (CAP is a 'superset' of 
iRIP which is a binding of iTIP so if you can do multipart in iTIP you can 
do it in the 'iRIP subset' of CAP...)

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0054F1E385256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>John wrote:</tt></font>
<br><font size=2><tt>&gt; No, we do not.</tt></font>
<br>
<br><font size=2 face="sans-serif">Weren't you arguing multipart/mixed
vs multipart/related w/Doug just a few postings back?? &nbsp;They appeared
to be that you agreed that mulitpart was in order, just you didnt necessarily
agree of the subtype. &nbsp;Was I wrong in reading _<u>this</u>_ thread
so far??</font>
<br>
<br><font size=2><tt>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;The thread you cite was an related to iMIP, which <br>
&gt; inherits MUA-based requirements from MIME. &nbsp;It does *not* mean
that <br>
&gt; every iCalendar-based application must support multipart.<br>
</tt></font>
<br><font size=2 face="sans-serif">I did not mean to add iMIP to this discussion
since its already baked and in the bag. &nbsp;I was merely trying to show
that we discussed the entire idea of multipart support a long time ago
and we agreed then that it was useful/necessary. &nbsp;The intent was/is
to show we've already covered this so why are we covering it again?? </font>
<br>
<br><font size=2 face="sans-serif">Not every iCalendar application supports
multipart (check CalConnect results yourself). &nbsp;Due to this that means
some apps do not easily work with other iCalendar apps unless extra steps
are taken on someones part. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Ill let the WG thrash over &quot;do
we want to have multipart in CAP&quot; as long as they like since Ive alrady
expressed my views on it. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">I will keep advocating that in CAP we
must be much much more precise in specifying _<u>how</u>_ multipart is
to be supported since CUAs already support multipart in iTIP you'd have
to be foolish to regress it but you'd be wise to more precisely codify
it that it was in iTIP. &nbsp;(CAP is a 'superset' of iRIP which is a binding
of iTIP so if you can do multipart in iTIP you can do it in the 'iRIP subset'
of CAP...)</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0054F1E385256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:36:50 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17828
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:36:50 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFLrP01040
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:21:53 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFLqk01034
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:21:53 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 3E4BC1552D; Tue, 10 Sep 2002 17:21:53 +0200 (CEST)
Date: Tue, 10 Sep 2002 17:21:53 +0200
From: Andrea Campi <a.campi@inet.it>
To: Bruce_Kahn@notesdev.ibm.com
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
Message-ID: <20020910152152.GE83146@inet.it>
References: <20020910102104.GD83146@inet.it> <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Tue, Sep 10, 2002 at 10:58:04AM -0400, Bruce_Kahn@notesdev.ibm.com wrote:
> Andrea wrote on 09/10/2002 06:21:04 AM:
> > I agree that we don't HAVE to support multipart. Now, if there was
> > a compelling reason, or a real advantage, then we can decided
> > whether to make it mandatory or optional.
> 
> I will ask the same question again so that I hear the answer from those 
> that think multipart support is NOT necessary in CAP: How do you expect to 
> deal with ATTACHments and richer content renderings (ie: ALTREPs) if you 
> do NOT have multipart support in the protocol/engine?  (Will they 

You are right, and I agree with you that for ATTACHments to work we
do need to support multipart. I was really focusing more on the
protocol than the bigger picture.

However, I still think my original objection stands, so let me
reformulate my question.

What if we mandated that the reply to a SEARCH command (just to
pick the most complex example) is contained in one or more VCALENDAR
objects in the MIME root, and additional MIME parts can be sent
for referenced ATTACHments? Would this break any functionality?
Would this be against any RFC?

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:40:15 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17904
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:40:14 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFZCj02843
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:35:12 -0700 (PDT)
Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFZBk02837
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:35:11 -0700 (PDT)
Received: from inet-mail2.oracle.com (localhost [127.0.0.1])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AFZ8Z03829
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:35:08 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AFZ7Z03803
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:35:07 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AFZ6v19952
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:35:06 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AFZ2f19788
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:35:03 -0600 (MDT)
Message-ID: <3D7E1122.70716473@oracle.com>
Date: Tue, 10 Sep 2002 11:34:58 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: [Fwd: How To Handle Attachments]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



[I sent this about an hour ago. It does not seem to have
gotten through. Perhaps my new e-mail address was recognized.
I resubscribed to the list with my new e-mail address.
Sorry if this message ends up appearing in duplicate.]

A few questions about how to handle attachments:

  1) How can a CUA get all properties of a component except an
     attachment, which may be very big?

  2) How do we delete or modify an attachment if a component
     has multiple attachments? CAP draft specifies that the
     CUA can specify a part of the attachment such that it
     is uniquely identified. That means that the CUA must download
     the entire attachment, upload part of it in the MODIFY command,
     and upload the entire new attachment. How will the CUA know
     up to now many bytes of the old attachment uniquely identifies
     it.

  3) In section 9.5 (MODIFY Command):

        The ATTACHMENT value supplied by the CUA MUST BE
        valid encoded information.

     What does this mean? Does it mean that the encoding must match
     the "ENCODING" parameter? Can this always be verified?
 
  4) How can a CUA let a user know that an event has an attachment
     without downloading it? This can allow the attachment to be
     downloaded only if the users "clicks" on it.

George


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:42:13 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17984
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:42:13 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFYca02741
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:34:38 -0700 (PDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFYbk02735
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:34:37 -0700 (PDT)
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AFYX727017
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:34:33 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AFYWp26984
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:34:32 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AFYTv18643
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:34:30 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AFYOf18464
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:34:24 -0600 (MDT)
Message-ID: <3D7E10FE.B6D4C76D@oracle.com>
Date: Tue, 10 Sep 2002 11:34:22 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



[I sent this about an hour ago. It does not seem to have
gotten through. Perhaps my new e-mail address was recognized.
I resubscribed to the list with my new e-mail address.
Sorry if this message ends up appearing in duplicate.]

  I also agree that we need a compelling reason.

  I feel that the simpler the better. Furthermore, we should
try to agree on a specific format rather than having multiple
possibilities. This will make co-existence much easier. (We
had interoperability problems during calconnect due to the
many different ways one can put an iCalendar into a MIME
object.)

  The only reason I see that one may want to support multipart is
for attachments. However, they can also be put inline into the
icalendar object. 

George

Andrea Campi wrote:
> 
> On Tue, Sep 10, 2002 at 10:38:04AM +0100, Mark Davidson wrote:
> > >>In any case I think we all seem to agree that multipart support is
> > >>necessary (if not implicitly mandated),
> > >
> > >No, we do not.  The thread you cite was an related to iMIP, which
> > >inherits MUA-based requirements from MIME.  It does *not* mean that
> > >every iCalendar-based application must support multipart.
> >
> > I agree with John. I see no reason why a CUA needs to use multipart
> > anything when talking to a CAP server. It just adds another wrapping of the
> > data that adds nothing and making parsing harder.
> >
> 
> I agree that we don't HAVE to support multipart. Now, if there was
> a compelling reason, or a real advantage, then we can decided
> whether to make it mandatory or optional.
> 
> Bye,
>         Andrea
> 
> --
> Andrea Campi                              mailto:a.campi@inet.it
> I.NET S.p.A.                              http://www.inet.it
> Direzione Tecnica - R&D                   phone: +39 02 32863 ext 1
> v. Darwin, 85 - I-20019                   fax: +39 02 32863 ext 7705
> Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:44:22 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18016
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:44:22 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFa5402983
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:36:05 -0700 (PDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFa4k02977
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:36:04 -0700 (PDT)
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AFa0e17789
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:36:00 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AFa0C17782
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:36:00 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AFZwv21554
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:35:59 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AFZpf21371
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:35:54 -0600 (MDT)
Message-ID: <3D7E1155.8A541A69@oracle.com>
Date: Tue, 10 Sep 2002 11:35:49 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: New Paramaters/New Properties Sections
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



[I sent this about an hour ago. It does not seem to have
gotten through. Perhaps my new e-mail address was recognized.
I resubscribed to the list with my new e-mail address.
Sorry if this message ends up appearing in duplicate.]


Two new sub-sections have been added in the latest version
of CAP:

   2.1.1 New Parameters (summary)
   2.1.2 New Properties (summary)

  These contain summary definitions of the new parameters and
properties. The formal definitions are found later in section 6.
Should we remove 2.1.1 and 2.1.2 since they duplicate
information and keeping them in sync with the formal definitions
can be troublesome?

  Do people see a need for them. I can remove the sub-sections
if people feel that they are more troublesome that they are worth.

George


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:46:09 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18083
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:46:09 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFcNJ03284
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:38:23 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFcMk03278
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:38:22 -0700 (PDT)
To: John Stracke <jstracke@centivinc.com>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OFF3FD14AD.32F8946F-ON85256C30.00550AA0-85256C30.0055E950@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 11:38:18 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 11:32:00 AM,
	Serialize complete at 09/10/2002 11:32:00 AM
Content-Type: multipart/alternative; boundary="=_alternative 0055E94B85256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0055E94B85256C30_=
Content-Type: text/plain; charset="US-ASCII"

John wrote:
>--> > The "ALTREP" property parameter value might point to a "text/html"
> >    content portion.
> >
> >If it is not talking about another body part, what is it?

Thats now the way CIDs are defined in RFC 2392:
1. Introduction

   The use of [MIME] within email to convey Web pages and their
   associated images requires a URL scheme to permit the HTML to refer
   to the images or other data included in the message.  The Content-ID
   Uniform Resource Locator, "cid:", serves that purpose.

"included in the message" is not "in _another_ message" at least to me.

To refer to a MIME entity in another message you'd have to use the MID: 
schema which allows for references to other messages OR parts within them:

     mid-url       = "mid" ":" message-id [ "/" content-id ]

>MIME multipart is *not* valid in 2445.

Where does 2445 say that?  MIME multipart encoding is not mentioned either 
way in RFC 2445 unless you have a special copy that I dont. RFC 2445 is 
essentially a long winded registration of the MIME text/calendar type and 
subtypes...

Given I can have a CID: URI in iCalendar I damn sure think that mulitpart 
IS 'valid'.  Its probably more appropriate relative to iTIP/iMIP but its 
still relevant to iCalendar.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0055E94B85256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>John wrote:<br>
&gt;--&gt; &gt; The &quot;ALTREP&quot; property parameter value might point
to a &quot;text/html&quot;<br>
&gt; &gt; &nbsp; &nbsp;content portion.<br>
&gt; &gt;<br>
&gt; &gt;If it is not talking about another body part, what is it?<br>
</tt></font>
<br><font size=2><tt>Thats now the way CIDs are defined in RFC 2392:</tt></font>
<br><font size=2><tt>1. Introduction<br>
<br>
 &nbsp; The use of [MIME] within email to convey Web pages and their<br>
 &nbsp; associated images requires a URL scheme to permit the HTML to refer<br>
 &nbsp; to the images or other data included in the message. &nbsp;The
Content-ID<br>
 &nbsp; Uniform Resource Locator, &quot;cid:&quot;, serves that purpose.</tt></font>
<br>
<br><font size=2 face="sans-serif">&quot;included in the message&quot;
is not &quot;in _<u>another</u>_ message&quot; at least to me.</font>
<br>
<br><font size=2 face="sans-serif">To refer to a MIME entity in another
message you'd have to use the MID: schema which allows for references to
other messages OR parts within them:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp;mid-url &nbsp; &nbsp; &nbsp; =
&quot;mid&quot; &quot;:&quot; message-id [ &quot;/&quot; content-id ]<br>
</tt></font>
<br><font size=2><tt>&gt;MIME multipart is *not* valid in 2445.<br>
</tt></font>
<br><font size=2 face="sans-serif">Where does 2445 say that? &nbsp;MIME
multipart encoding is not mentioned either way in RFC 2445 unless you have
a special copy that I dont. RFC 2445 is essentially a long winded registration
of the MIME text/calendar type and subtypes...</font>
<br>
<br><font size=2 face="sans-serif">Given I can have a CID: URI in iCalendar
I damn sure think that mulitpart IS 'valid'. &nbsp;Its probably more appropriate
relative to iTIP/iMIP but its still relevant to iCalendar.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
--=_alternative 0055E94B85256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:46:11 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18097
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:46:10 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFg7q03552
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:42:07 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFg4k03539
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:42:04 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AFfxbB009972
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:42:04 -0700
Message-ID: <3D7E11CD.2B742359@Royer.com>
Date: Tue, 10 Sep 2002 09:37:50 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OF8AE31CF1.DFF31E17-ON85256C2F.00541F0A-85256C2F.00571B88@iris.com> <3D7CCAE4.8020104@centivinc.com>
Content-Type: multipart/mixed;
 boundary="------------DF02668D7806CD886E485199"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------DF02668D7806CD886E485199
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Stracke wrote:
> 
> Bruce_Kahn@notesdev.ibm.com wrote:
> 
> > In this case we are trying to represent the VAGENDA by lots of smaller
> > blobs of data.
> 
> I'm not sure that's true.  We're trying to represent the answer to a
> query such as "what objects are in the VAGENDA?".  That answer is not
> the VAGENDA itself.

However one of the query replies can be get me everything
in a VAGENDA. And part of CAP we agreed to allow synchronization.
And synchronization is going to require that we allow fetching
and setting full VAGENDAs.
--------------DF02668D7806CD886E485199
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------DF02668D7806CD886E485199--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:48:16 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18126
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:48:15 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFghu03650
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:42:43 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AFgfk03644
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:42:42 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091011511323261
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:51:13 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 11:40:49 -0400
Message-ID: <3D7E1281.1040600@centivinc.com>
Date: Tue, 10 Sep 2002 11:40:49 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OFDC2A8C6C.91A5F601-ON85256C30.004FD41E-85256C30.0050519D@iris.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 15:40:49.0763 (UTC) FILETIME=[702BC330:01C258E0]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

> Mark  wrote on 09/10/2002 05:38:04 AM:
> > I agree with John. I see no reason why a CUA needs to use multipart
> > anything when talking to a CAP
> > server. It just adds another wrapping of the data that adds nothing
> > and making parsing harder.
>
> Then how do you expect the ATTACHments and other related kinds of data 
> is going to get to the server?  Does the server magically regenerate 
> the richer HTML rendering of DESCRIPTION from thin air or by some 
> heuristic?  That data has to get to the server somehow.

Wrong.  A CAP server will not store HTML, or other non-iCalendar data. 
 Notes can do it, but that's because Notes is a generic MIME store, 
which is not a viable approach for a scalable CS.

A CAP CS which received an iCalendar containing an ATTACH would have to 
reject it.

-- 
/===========================================\
|John Stracke      |jstracke@centivinc.com  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|You buttered your bread, now lie in it.    |
\===========================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:51:50 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18208
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:51:49 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AFjxg04074
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:45:59 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFjwk04069
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:45:58 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AFjvbB009997
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:45:59 -0700
Message-ID: <3D7E12BC.7EEB9803@Royer.com>
Date: Tue, 10 Sep 2002 09:41:48 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com>
Content-Type: multipart/mixed;
 boundary="------------1ACF8A0B694A4D4600CD4A7E"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


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

John Stracke wrote:
> 
> Bruce_Kahn@notesdev.ibm.com wrote:
> 
> > In any case I think we all seem to agree that multipart support is
> > necessary (if not implicitly mandated),
> 
> No, we do not.  The thread you cite was an related to iMIP, which
> inherits MUA-based requirements from MIME.  It does *not* mean that
> every iCalendar-based application must support multipart.

Nor did Bruce say it was mandated. There are implementations
that use multipart - we can not just decide they have to break.
--------------1ACF8A0B694A4D4600CD4A7E
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------1ACF8A0B694A4D4600CD4A7E--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 11:55:44 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18287
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:55:44 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AFnWW04609
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:49:32 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFnVk04605
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:49:31 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AFnTbB010014
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:49:32 -0700
Message-ID: <3D7E138F.6648A937@Royer.com>
Date: Tue, 10 Sep 2002 09:45:19 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com> <3D7DBD7C.7070409@samsungcontact.com> <20020910102104.GD83146@inet.it>
Content-Type: multipart/mixed;
 boundary="------------367D7BD40E2917F4356AE2F7"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------367D7BD40E2917F4356AE2F7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> On Tue, Sep 10, 2002 at 10:38:04AM +0100, Mark Davidson wrote:
> > >>In any case I think we all seem to agree that multipart support is
> > >>necessary (if not implicitly mandated),
> > >
> > >No, we do not.  The thread you cite was an related to iMIP, which
> > >inherits MUA-based requirements from MIME.  It does *not* mean that
> > >every iCalendar-based application must support multipart.
> >
> > I agree with John. I see no reason why a CUA needs to use multipart
> > anything when talking to a CAP server. It just adds another wrapping of the
> > data that adds nothing and making parsing harder.
> >
> 
> I agree that we don't HAVE to support multipart. Now, if there was
> a compelling reason, or a real advantage, then we can decided
> whether to make it mandatory or optional.

No one is saying that all CUA's must support multipart.
We are saying that CUA's and CS's MAY support multipart.

We are also saying that some 244[567] implementations
already support multipart. Removing that support is not
in our charter. If you implement a CUA that can not support
attachments - that's fine.
--------------367D7BD40E2917F4356AE2F7
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------367D7BD40E2917F4356AE2F7--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:10:03 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18708
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:10:03 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AG3AM05816
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:03:10 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AG39k05812
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:03:09 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012115030915
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:11:50 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:01:27 -0400
Message-ID: <3D7E1757.1020306@centivinc.com>
Date: Tue, 10 Sep 2002 12:01:27 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: New Paramaters/New Properties Sections
References: <3D7E1155.8A541A69@oracle.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:01:27.0506 (UTC) FILETIME=[51EC5B20:01C258E3]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


George Babics wrote:

>Should we remove 2.1.1 and 2.1.2 since they duplicate
>information and keeping them in sync with the formal definitions
>can be troublesome?
>  
>
Or we could just include the lists, but remove the summaries, and mark 
2.1.1 and 2.1.2 as non-normative.

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:13:02 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18783
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:13:01 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AFxGf05303
	for ietf-calendar-bks; Tue, 10 Sep 2002 08:59:16 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFxFk05297
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:59:15 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AFxEbB010116
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 08:59:17 -0700
Message-ID: <3D7E15D9.F67B4906@Royer.com>
Date: Tue, 10 Sep 2002 09:55:05 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris.com>
Content-Type: multipart/mixed;
 boundary="------------4AA610627B428C51548045C9"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------4AA610627B428C51548045C9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce_Kahn@notesdev.ibm.com wrote:
> 
>....
> 
> Look at the issues we have now in iMIP w/multipart support.  Some CUAs
> don't support it at all (ie: no ATTACHments, etc)  Some CUAs take one
> approach that may be contrary to the multipart semantics.  Some CUAs
> take a 'hybrid' approach to multipart in order to be 'richer' and to
> support workflow w/the other CUAs.  Its a big hodgepodge that makes
> interop testing less that seamless.  As a big user of C&S I really
> like seamless.  Maybe its just me and most users want to have lots of
> limitations or hoops to jump thru....  Do we want to go thru this
> exact same morass with CAP as CAP clients start to develop??

We went through this debate before. (Yes with iMIP, because
iMIP was the only transport). We do not have to mandate that
all CUAs and CSs ->generate<- multipart.

Currently we allow a status reply to indicate that a CS can
not support recurrence rules. Do we want to add one that
says - sorry, I threw away your attachments?
--------------4AA610627B428C51548045C9
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------4AA610627B428C51548045C9--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:21:32 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18975
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:21:31 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AGDno06393
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:13:49 -0700 (PDT)
Received: from mail.samsungcontact.com (host195-89-159-51.uk.regusnet.com [195.89.159.51])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AGDlk06386
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:13:47 -0700 (PDT)
Received: from mail.samsungcontact.com (root@localhost)
	by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g8AGDjK13994;
	Tue, 10 Sep 2002 17:13:45 +0100
Received: from samsungcontact.com (host195-89-159-62.uk.regusnet.com 195.89.159.62)
        by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0)
        via ESMTP; Tue, 10 Sep 2002 17:13:45 +0100 (BST)
Message-ID: <3D7E1A38.8090204@samsungcontact.com>
Date: Tue, 10 Sep 2002 17:13:44 +0100
From: Mark Davidson <markd@samsungcontact.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bruce_Kahn@notesdev.ibm.com
CC: Andrea Campi <a.campi@inet.it>, ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

> I will ask the same question again so that I hear the answer from those 
> that think multipart support is NOT necessary in CAP: How do you expect 
> to deal with ATTACHments and richer content renderings (ie: ALTREPs) if 
> you do NOT have multipart support in the protocol/engine?  (Will they 
> magically appear in my local CUA or will it have to download them using 
> some undocumented CAP command or OOB mechanism??)
> 

I must admit, that because there was nothing about this in the draft, I assumed that the CS just 
stored URIs or encoded attachments. But I did forget about ALTREP.

But I still don't think multipart it the way to go.

If we allow multipart/related with URIs pointing to attachments, then how do we get the data back 
out of the CS. If I do a search, then I just get objects and properties.

Either we need some commands for storing and retrieving attachments in the CS, or we change search 
to return multipart/related.

I would prefer some new commands and stick to text/icalendar as our command format.

Mark



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:23:27 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19041
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:23:26 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AG8qj06081
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:08:52 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AG8pk06075
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:08:51 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012173226988
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:17:32 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:07:09 -0400
Message-ID: <3D7E18AD.3030501@centivinc.com>
Date: Tue, 10 Sep 2002 12:07:09 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com> <3D7E12BC.7EEB9803@Royer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:07:09.0438 (UTC) FILETIME=[1DBB09E0:01C258E4]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>John Stracke wrote:
>  
>
>>Bruce_Kahn@notesdev.ibm.com wrote:
>>
>>    
>>
>>>In any case I think we all seem to agree that multipart support is
>>>necessary (if not implicitly mandated),
>>>      
>>>
>>No, we do not.  The thread you cite was an related to iMIP, which
>>inherits MUA-based requirements from MIME.  It does *not* mean that
>>every iCalendar-based application must support multipart.
>>    
>>
>
>Nor did Bruce say it was mandated. There are implementations
>that use multipart - we can not just decide they have to break.
>
They use multipart for iMIP.  An iMIP message will never be presented 
directly to a CAP CS.  Instead, an MUA will accept the multipart, 
extract the text/calendar body part, and submit it to the CS via CAP.

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:25:28 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19128
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:25:27 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AG5Vd05939
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:05:31 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AG5Tk05935
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:05:30 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012141224395
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:14:12 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:03:48 -0400
Message-ID: <3D7E17E4.30201@centivinc.com>
Date: Tue, 10 Sep 2002 12:03:48 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OFDC2A8C6C.91A5F601-ON85256C30.004FD41E-85256C30.0050519D@iris.com> <3D7E1281.1040600@centivinc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:03:48.0776 (UTC) FILETIME=[A6207280:01C258E3]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


John Stracke wrote:

> Wrong.  A CAP server will not store HTML, or other non-iCalendar data. 
> Notes can do it, but that's because Notes is a generic MIME store, 
> which is not a viable approach for a scalable CS.
>
> A CAP CS which received an iCalendar containing an ATTACH would have 
> to reject it.
>
Correction: an ATTACH with a URI which referenced an external entity 
would be fine.

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:26:52 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19176
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:26:51 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AGJu506828
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:19:56 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AGJsk06822
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:19:54 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AGJsbB010271
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:19:56 -0700
Message-ID: <3D7E1AB0.3F2376DB@Royer.com>
Date: Tue, 10 Sep 2002 10:15:44 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OFDC2A8C6C.91A5F601-ON85256C30.004FD41E-85256C30.0050519D@iris.com> <3D7E1281.1040600@centivinc.com>
Content-Type: multipart/mixed;
 boundary="------------FDFBFBEED2366C16E779FB91"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------FDFBFBEED2366C16E779FB91
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Stracke wrote:
> 
> Bruce_Kahn@notesdev.ibm.com wrote:
> 
> > Mark  wrote on 09/10/2002 05:38:04 AM:
> > > I agree with John. I see no reason why a CUA needs to use multipart
> > > anything when talking to a CAP
> > > server. It just adds another wrapping of the data that adds nothing
> > > and making parsing harder.
> >
> > Then how do you expect the ATTACHments and other related kinds of data
> > is going to get to the server?  Does the server magically regenerate
> > the richer HTML rendering of DESCRIPTION from thin air or by some
> > heuristic?  That data has to get to the server somehow.
> 
> Wrong.  A CAP server will not store HTML, or other non-iCalendar data.
>...

A CAP server needs to store ALL valid iCalendar data, including
any included attachments. No place in CAP did we say that ATTACH
is invalid.

>  Notes can do it, but that's because Notes is a generic MIME store,
> which is not a viable approach for a scalable CS.

"Notes" can do more than a CS. Included attachments are part
of iCalendar.

> A CAP CS which received an iCalendar containing an ATTACH would have to
> reject it.

No. A CS that does not support ATTACH would have to reject it.
However a CS that does support ATTACH would not reject it.

We have never been chartered to reduce the 2445 specification.
We have never had any debate or agreement to disallow some valid
iCalendar objects. In fact the entire purpose of CAP is to
allow for the storage of iCalendar objects - not just some
of them.
--------------FDFBFBEED2366C16E779FB91
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------FDFBFBEED2366C16E779FB91--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:38:04 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19410
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:38:03 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AGOVL07123
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:24:31 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AGOTk07117
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:24:29 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012331131510
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:33:11 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:22:47 -0400
Message-ID: <3D7E1C57.6040706@centivinc.com>
Date: Tue, 10 Sep 2002 12:22:47 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF9ABC3D0F.ECA063FC-ON85256C30.0052A02D-85256C30.0053B87D@iris.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:22:47.0890 (UTC) FILETIME=[4D177320:01C258E6]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

>
> John wrote:
> > > In this case we are trying to represent the VAGENDA by lots of 
> smaller
> > > blobs of data.
> >
> > I'm not sure that's true.  We're trying to represent the answer to a
> > query such as "what objects are in the VAGENDA?".  That answer is not
> > the VAGENDA itself.
>
> "Represent the VAGENDA by lots of smaller blobs of data" = "Represent 
> the answer to the query such as 'what objects are in the VAGENDA?'' 

They are not the same at all.  If you wanted a root for the latter, it 
would have to be the query.

> > I'll say it again: a CAP CUA is not necessarily an MUA.  This means 
> that
> > RFC-2049 does not apply to CAP.  It applies to iMIP only because iMIP
> > runs over email, and so an iMIP implementation is necessarily an MUA.
>
> Dont try to split hairs here!  Using that logic I could claim that my 
> HTTP server and browsers dont have to be MIME complaint too

They aren't.  Go read RFC-2616: HTTP does not actually use MIME.  From 
the introduction:

   Messages are passed in a format similar to
   that used by Internet mail [9] as defined by the Multipurpose
   Internet Mail Extensions (MIME) [7].

Since RFC-2445 does not reference RFC-2049, there is no sensible basis 
for asserting that any iCalendar implementation is bound by RFC-2049. 
 Likewise, although BEEP does reference RFC-2045 (the basic MIME 
format), it does not reference RFC-2049--if it did, one could argue that 
CAP was bound by RFC-2049.

More to the point, there is no good reason for CAP implementations to be 
bound by RFC-2049.  The requirements of RFC-2049 are designed for MUAs; 
they do not make any sense at all for CUAs.  For example, RFC-2049 
requires text/plain.  What would it mean if a CS received a text/plain 
message? What would you expect it to do with it? Or how about 
message/rfc822, or application/octet-stream (the MUA must offer the 
ability to save the decoded body part into a file)?

The only content type that makes any sense at all in CAP is text/calendar.

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:40:54 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19504
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:40:54 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AGVAm07563
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:31:10 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AGV8k07558
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:31:09 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012395106501
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:39:51 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:29:27 -0400
Message-ID: <3D7E1DE7.7000003@centivinc.com>
Date: Tue, 10 Sep 2002 12:29:27 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OFE9994917.ABBC0BBA-ON85256C30.0053D036-85256C30.0054F1E8@iris.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:29:27.0497 (UTC) FILETIME=[3B46A390:01C258E7]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

>  (CAP is a 'superset' of iRIP which is a binding of iTIP so if you can 
> do multipart in iTIP you can do it in the 'iRIP subset' of CAP...) 

You cannot do multipart in iTIP.  You can do it in a MIME message which 
contains an iTIP object, but an iTIP object is not itself a MIME 
message.  The same can be said for iCalendar in general; although an 
iCalendar object can be carried in a MIME message, it is not inherently 
a MIME object.  See RFC-2445:

   This memo is formatted as a registration for a MIME media type per
   [RFC 2048]. However, the format in this memo is equally applicable
   for use outside of a MIME message content type.

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:42:55 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19597
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:42:54 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AGblq07969
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:37:47 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AGbkk07964
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:37:46 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012462827825
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:46:28 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:36:05 -0400
Message-ID: <3D7E1F75.4010100@centivinc.com>
Date: Tue, 10 Sep 2002 12:36:05 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris.com> <3D7E15D9.F67B4906@Royer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:36:05.0385 (UTC) FILETIME=[286F8790:01C258E8]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>Do we want to add one that
>says - sorry, I threw away your attachments?
>
No, we want an error message that says, "your request was not of type 
text/calendar; go away".

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:43:18 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19614
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:43:17 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AGcgE08023
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:38:42 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AGcfk08017
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:38:41 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012472411416
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:47:24 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:37:00 -0400
Message-ID: <3D7E1FAC.3070504@centivinc.com>
Date: Tue, 10 Sep 2002 12:37:00 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com> <3D7DBD7C.7070409@samsungcontact.com> <20020910102104.GD83146@inet.it> <3D7E138F.6648A937@Royer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:37:00.0168 (UTC) FILETIME=[4916C080:01C258E8]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>No one is saying that all CUA's must support multipart.
>We are saying that CUA's and CS's MAY support multipart.
>
But MAYs and SHOULDs are a nightmare; they make interop incredibly hard, 
and should be used only when totally unavoidable.

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:45:24 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19662
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:45:24 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AGaBv07850
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:36:11 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AGaAk07844
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:36:10 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AGa8bB010424
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:36:11 -0700
Message-ID: <3D7E1E7F.BC74DD2B@Royer.com>
Date: Tue, 10 Sep 2002 10:31:59 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <3D7E10FE.B6D4C76D@oracle.com>
Content-Type: multipart/mixed;
 boundary="------------53E98F5C76FBBDF2A8DC3322"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------53E98F5C76FBBDF2A8DC3322
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

George Babics wrote:

>   I also agree that we need a compelling reason.
> 
>   I feel that the simpler the better. Furthermore, we should
> try to agree on a specific format rather than having multiple
> possibilities. This will make co-existence much easier. (We
> had interoperability problems during calconnect due to the
> many different ways one can put an iCalendar into a MIME
> object.)

MIME already specifies how a MIME objects are formed (and there
is not one way). So do you mean with respect to VQUERY replies?
As in how many VCALENDAR objects per MIME object? And how
many MIME objects?

Each text/calenendar MIME object is parsable now. If it
contains one or multiple VCALENDAR objects and if it contains
(or is part of) one or multiple body parts. What do we need to
specify?

If any iCalendar object is part of any MIME object, for the
purpose of parsing and storing the iCalendar object, each
text/calendar object is the root of its view. Start from
that point and extract and store all CIDs and MIDs.
If there are multiple text/calendar objects, each gets
its view from its self. This is not unique to iCalendar.
Its what MIME is. That's why they invented CID's and MIDs.

MIME and iCalendar allow for alternate representations now.
If one CUA does not store all of it - that is fine. But
I see no reason to break implementations when is all a CUA
or CS has to do is ignore representations that it can not
handle - and pass back a status code.

If a CUA or CS passes back an empty MULTIPART capability,
then don't send it any and inform the user they need to
select another vender or implementation. If that is something
that some users will never use or need - fine.

> The only reason I see that one may want to support multipart is
> for attachments. However, they can also be put inline into the
> icalendar object.

That's implying that CAP needs to redefine 2445 and limit
it to inline only.
--------------53E98F5C76FBBDF2A8DC3322
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------53E98F5C76FBBDF2A8DC3322--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:46:28 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19699
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:46:27 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AGRdF07327
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:27:39 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AGRbk07321
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:27:38 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012362002622
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:36:20 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:25:56 -0400
Message-ID: <3D7E1D14.9070304@centivinc.com>
Date: Tue, 10 Sep 2002 12:25:56 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:25:56.0553 (UTC) FILETIME=[BD8B2390:01C258E6]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

>
> Andrea wrote on 09/10/2002 06:21:04 AM:
> > I agree that we don't HAVE to support multipart. Now, if there was
> > a compelling reason, or a real advantage, then we can decided
> > whether to make it mandatory or optional.
>
> Part of the confusion as to _if_ we need multipart comes from Johns 
> mention of iMIP (per my citation).  While the citation came from an 
> iMIP thread it does apply to CAP indirectly.  Since CAP essentially 
> encapsulates iRIP (the 'real time' binding of iTIP) it needs to have 
> the same abilities we have already covered and agreed on.

(a) How can you argue based on iRIP requirements when iRIP has been 
abandoned for at least 3 years?

(b) The argument that iMIP required multipart did not apply to iRIP, 
because an iRIP implementation would not have been an MUA, either.

> After all, if I can send a simple iMIP meeting invite w/an attached 
> agenda or related document NOW, why cant I use my "newer and improved" 
> CAP CUA to read it from the newer CAP server when I could do it using 
> POP3 or IMAP now?

Because a sensible CAP server will be backed by a relational database, 
and should not be required to store blobs.

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:48:23 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19740
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:48:22 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AGiFl08376
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:44:15 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AGiEk08372
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:44:14 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012525626793
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:52:56 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:42:32 -0400
Message-ID: <3D7E20F8.4070503@centivinc.com>
Date: Tue, 10 Sep 2002 12:42:32 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris> <3D7E1A38.8090204@samsungcontact.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:42:32.0819 (UTC) FILETIME=[0F5D4430:01C258E9]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Mark Davidson wrote:

> Either we need some commands for storing and retrieving attachments in 
> the CS,

...which would duplicate the functionality of WebDAV (RFC-2518).

Actually, that gives me an idea.  The problem Bruce and Doug have raised 
is that an iMIP-aware MUA which forwards text/calendar to a CAP CS needs 
some place to store attached non-text/calendar content.  Why not copy 
those body parts into a WebDAV repository, and rewrite the text/calendar 
that goes to the CS to use an http: URL?  Or, if the MUA is getting its 
mail from an IMAP server, it could rewrite the text/calendar to use an 
imap: URL.  Either way, the arbitrary MIME blobs would live in an actual 
MIME store, and the CS would be relieved of the burden of having to cope 
with them.

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:49:32 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19763
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:49:31 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AGhw008350
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:43:58 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AGhvk08345
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:43:57 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AGhubB010493
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:43:58 -0700
Message-ID: <3D7E2053.F0DF0E43@Royer.com>
Date: Tue, 10 Sep 2002 10:39:47 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com> <3D7E12BC.7EEB9803@Royer.com> <3D7E18AD.3030501@centivinc.com>
Content-Type: multipart/mixed;
 boundary="------------E414A517C35EC348F1C9E0E8"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------E414A517C35EC348F1C9E0E8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Stracke wrote:
> 
> Doug Royer wrote:
> 
> >John Stracke wrote:
> >
> >
> >>Bruce_Kahn@notesdev.ibm.com wrote:
> >>
> >>
> >>
> >>>In any case I think we all seem to agree that multipart support is
> >>>necessary (if not implicitly mandated),
> >>>
> >>>
> >>No, we do not.  The thread you cite was an related to iMIP, which
> >>inherits MUA-based requirements from MIME.  It does *not* mean that
> >>every iCalendar-based application must support multipart.
> >>
> >>
> >
> >Nor did Bruce say it was mandated. There are implementations
> >that use multipart - we can not just decide they have to break.
> >
> They use multipart for iMIP.  An iMIP message will never be presented
> directly to a CAP CS. 

Why not? Its a valid iCalendar object.

> Instead, an MUA will accept the multipart,
> extract the text/calendar body part, and submit it to the CS via CAP.

Why? They are valid iCalendar objects.
--------------E414A517C35EC348F1C9E0E8
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------E414A517C35EC348F1C9E0E8--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 12:50:51 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19797
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 12:50:51 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AGanL07897
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:36:49 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AGamk07892
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:36:48 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091012453030911
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:45:30 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 12:35:06 -0400
Message-ID: <3D7E1F3A.7020904@centivinc.com>
Date: Tue, 10 Sep 2002 12:35:06 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OFF3FD14AD.32F8946F-ON85256C30.00550AA0-85256C30.0055E950@iris.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 16:35:06.0898 (UTC) FILETIME=[05931F20:01C258E8]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

>
> John wrote:
> >--> > The "ALTREP" property parameter value might point to a "text/html"
> > >    content portion.
> > >
> > >If it is not talking about another body part, what is it?
>
> Thats now the way CIDs are defined in RFC 2392: 

Go read what I actually wrote.  To quote 2392 again:

   The "cid" scheme refers to a specific body part of a
   message; its use is generally limited to references to other body
   parts in the same message as the referring body part.

In other words, cid: can refer to a different message, but usually doesn't.

> MIME multipart is *not* valid in 2445.
>
> Where does 2445 say that?  MIME multipart encoding is not mentioned 
> either way in RFC 2445

Right.  That means that you cannot assume that it is valid.  Therefore, 
it is not valid--in a standard, anything not specifically mentioned is 
forbidden.

> Given I can have a CID: URI in iCalendar I damn sure think that 
> mulitpart IS 'valid'.

No.  You can have a cid: URI that refers to an arbitrary message 
someplace out in the ether; or, if the iCalendar happens to be wrapped 
in a MIME multipart, you can have a cid: URI that points to a different 
body part in that multipart.

URIs always have this problem.  If you saw an example of HTML that used 
a gopher: URL, would you assume that all Web browsers MUST contain a 
Gopher client?

-- 
/=====================================================\
|John Stracke      |jstracke@centivinc.com            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 13:24:06 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20747
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 13:24:06 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AHF2c09917
	for ietf-calendar-bks; Tue, 10 Sep 2002 10:15:02 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AHF1k09913
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:15:01 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091013234326097
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:23:43 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 13:13:19 -0400
Message-ID: <3D7E282F.3090708@centivinc.com>
Date: Tue, 10 Sep 2002 13:13:19 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com> <3D7E12BC.7EEB9803@Royer.com> <3D7E18AD.3030501@centivinc.com> <3D7E2053.F0DF0E43@Royer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 17:13:19.0550 (UTC) FILETIME=[5C1A0DE0:01C258ED]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>John Stracke wrote:
>  
>
>>An iMIP message will never be presented
>>directly to a CAP CS. 
>>    
>>
>
>Why not? Its a valid iCalendar object.
>
No, it is a MIME message which *contains* an iCalendar object.  If it 
also contains an image/gif, then that image/gif must not go up to the CS.

-- 
/==========================================================\
|John Stracke      |jstracke@centivinc.com                 |
|Principal Engineer|http://www.centivinc.com               |
|Centiv            |My opinions are my own.                |
|==========================================================|
|"Where's your sense of adventure?" "Hiding under the bed."|
\==========================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 13:27:21 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20858
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 13:27:21 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AGuYP08937
	for ietf-calendar-bks; Tue, 10 Sep 2002 09:56:34 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AGuXk08933
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:56:33 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AGuWbB010616
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 09:56:34 -0700
Message-ID: <3D7E2346.1FFAE22C@Royer.com>
Date: Tue, 10 Sep 2002 10:52:22 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris> <3D7E1A38.8090204@samsungcontact.com>
Content-Type: multipart/mixed;
 boundary="------------868F09A44B1FA658D26DA43E"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------868F09A44B1FA658D26DA43E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Davidson wrote:
> 
> Bruce_Kahn@notesdev.ibm.com wrote:
> 
> > I will ask the same question again so that I hear the answer from those
> > that think multipart support is NOT necessary in CAP: How do you expect
> > to deal with ATTACHments and richer content renderings (ie: ALTREPs) if
> > you do NOT have multipart support in the protocol/engine?  (Will they
> > magically appear in my local CUA or will it have to download them using
> > some undocumented CAP command or OOB mechanism??)
> >
> 
> I must admit, that because there was nothing about this in the draft, I
> assumed that the CS just stored URIs or encoded attachments. But I did
> forget about ALTREP.
> 
> But I still don't think multipart it the way to go.
> 
> If we allow multipart/related with URIs pointing to attachments, then
> how do we get the data back out of the CS. If I do a search, then I
> just get objects and properties.

SELECT * FROM VEVENT where UID = 'a-id'

If it has inline attachments, they will be included. Where in
CAP did it say that we only allow for some valid iCalendar objects?
If your CUA could not support multipart, then you could not have
put it into the CS. If your CUA can not support multipart and
you contact a CS that is not yours, and the CS replies with
a multipart message, then the CU has two choices, live with the
error, or get another CUA.

ATTACHMENTS are part of iCalendar as is ALTREP. If a CUA/CS does
not wish to fully implement iCalendar - fine. But we can not
mandate that no CUA or CS can fully implement iCalendar.

> Either we need some commands for storing and retrieving attachments 
> in the CS, or we change search to return multipart/related.

No, an iCalendar object is the root of its tree. A CREATE, DELETE,
MODIFY, and VQUERY can work with any iCalendar object. What is
broken?

> I would prefer some new commands and stick to text/icalendar as our
> command format.

Where in CAP do we limit iCalendar objects to no attach or altrep?
Do you want new commands that say CREATE-NOT-COMPLEX, ... ?
--------------868F09A44B1FA658D26DA43E
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------868F09A44B1FA658D26DA43E--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 13:35:31 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21049
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 13:35:31 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AHHrc10103
	for ietf-calendar-bks; Tue, 10 Sep 2002 10:17:53 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AHHqk10096
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:17:52 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091013263500965
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:26:35 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 13:16:11 -0400
Message-ID: <3D7E28DB.8060600@centivinc.com>
Date: Tue, 10 Sep 2002 13:16:11 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OFDC2A8C6C.91A5F601-ON85256C30.004FD41E-85256C30.0050519D@iris.com> <3D7E1281.1040600@centivinc.com> <3D7E1AB0.3F2376DB@Royer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 17:16:11.0368 (UTC) FILETIME=[C2836680:01C258ED]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>We have never had any debate or agreement to disallow some valid
>iCalendar objects. In fact the entire purpose of CAP is to
>allow for the storage of iCalendar objects - not just some
>of them.
>
But an HTML body part is not an iCalendar object.

-- 
/==========================================================\
|John Stracke      |jstracke@centivinc.com                 |
|Principal Engineer|http://www.centivinc.com               |
|Centiv            |My opinions are my own.                |
|==========================================================|
|"Where's your sense of adventure?" "Hiding under the bed."|
\==========================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 13:58:15 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21658
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 13:58:15 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AHheL11472
	for ietf-calendar-bks; Tue, 10 Sep 2002 10:43:40 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AHhdk11467
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:43:39 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AHhdbB011017
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:43:41 -0700
Message-ID: <3D7E2E51.BFBB6B05@Royer.com>
Date: Tue, 10 Sep 2002 11:39:29 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com> <3D7DBD7C.7070409@samsungcontact.com> <20020910102104.GD83146@inet.it> <3D7E138F.6648A937@Royer.com> <3D7E1FAC.3070504@centivinc.com>
Content-Type: multipart/mixed;
 boundary="------------113A88954D6406437ACF217B"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------113A88954D6406437ACF217B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Stracke wrote:
> 
> Doug Royer wrote:
> 
> >No one is saying that all CUA's must support multipart.
> >We are saying that CUA's and CS's MAY support multipart.
> >
> But MAYs and SHOULDs are a nightmare; they make interop incredibly hard,
> and should be used only when totally unavoidable.

This debate has been going on for years. I think
it is time to declare it unavoidable.
--------------113A88954D6406437ACF217B
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------113A88954D6406437ACF217B--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 13:58:15 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21659
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 13:58:15 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AHf2h11120
	for ietf-calendar-bks; Tue, 10 Sep 2002 10:41:02 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AHf1k11114
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:41:01 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AHf0bB010994
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:41:02 -0700
Message-ID: <3D7E2DB2.284A9556@Royer.com>
Date: Tue, 10 Sep 2002 11:36:50 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <3D7E1122.70716473@oracle.com>
Content-Type: multipart/mixed;
 boundary="------------C7CEB393F89D7342C4CBD9C0"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------C7CEB393F89D7342C4CBD9C0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

George Babics wrote:
> 
> [I sent this about an hour ago. It does not seem to have
> gotten through. Perhaps my new e-mail address was recognized.
> I resubscribed to the list with my new e-mail address.
> Sorry if this message ends up appearing in duplicate.]
> 
> A few questions about how to handle attachments:
> 
>   1) How can a CUA get all properties of a component except an
>      attachment, which may be very big?


>   2) How do we delete or modify an attachment if a component
>      has multiple attachments? CAP draft specifies that the
>      CUA can specify a part of the attachment such that it
>      is uniquely identified. That means that the CUA must download
>      the entire attachment, upload part of it in the MODIFY command,
>      and upload the entire new attachment. How will the CUA know
>      up to now many bytes of the old attachment uniquely identifies
>      it.

The ultimate purpose of an attachment is for the CU/CUA. So
there is no way for a CU to know they wanted it modified, unless
they have already have it downloaded or do the download. Ether
way - it is going to have to be downloaded.

>   3) In section 9.5 (MODIFY Command):
> 
>         The ATTACHMENT value supplied by the CUA MUST BE
>         valid encoded information.
> 
>      What does this mean? Does it mean that the encoding must match
>      the "ENCODING" parameter? Can this always be verified?

The entire quote is:

   When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
   identify the contents of the ATTACHMENT value in the old-values in
   order to delete them.  When the CS compares the attachment data it is
   compared in its binary form.  The ATTACHMENT value supplied by the
   CUA MUST BE valid encoded information.

I think we can delete that last sentence as the comparison
is done in its binary form.
	

>   4) How can a CUA let a user know that an event has an attachment
>      without downloading it? This can allow the attachment to be
>      downloaded only if the users "clicks" on it.

So download it? Again - how the the CU know that is what
they wanted to do without first knowing what it is?

There is no requirement that just because a CUA gets an
iCalendar object with a huge attachment, that the CUA must
store it - the CU can reject it.
--------------C7CEB393F89D7342C4CBD9C0
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------C7CEB393F89D7342C4CBD9C0--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 14:00:39 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21771
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:00:39 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AHckZ10812
	for ietf-calendar-bks; Tue, 10 Sep 2002 10:38:46 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AHcjk10806
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:38:45 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AHcTbB010952
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:38:46 -0700
Message-ID: <3D7E2D1B.5FECCBC@Royer.com>
Date: Tue, 10 Sep 2002 11:34:19 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris.com> <3D7E1D14.9070304@centivinc.com>
Content-Type: multipart/mixed;
 boundary="------------C3B5C87A852246BB3DA1D9A0"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------C3B5C87A852246BB3DA1D9A0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Stracke wrote:
> 
> Bruce_Kahn@notesdev.ibm.com wrote:
> 
> >
> > Andrea wrote on 09/10/2002 06:21:04 AM:
> > > I agree that we don't HAVE to support multipart. Now, if there was
> > > a compelling reason, or a real advantage, then we can decided
> > > whether to make it mandatory or optional.
> >
> > Part of the confusion as to _if_ we need multipart comes from Johns
> > mention of iMIP (per my citation).  While the citation came from an
> > iMIP thread it does apply to CAP indirectly.  Since CAP essentially
> > encapsulates iRIP (the 'real time' binding of iTIP) it needs to have
> > the same abilities we have already covered and agreed on.
> 
> (a) How can you argue based on iRIP requirements when iRIP has been
> abandoned for at least 3 years?

It was abandoned because we agreed to incorporate its features into CAP.

> (b) The argument that iMIP required multipart did not apply to iRIP,
> because an iRIP implementation would not have been an MUA, either.

However ATTACH and ALTREP is part of iCalendar and iTIP as well
being part of iMIP and CAP and were also part of iRIP.

> > After all, if I can send a simple iMIP meeting invite w/an attached
> > agenda or related document NOW, why cant I use my "newer and improved"
> > CAP CUA to read it from the newer CAP server when I could do it using
> > POP3 or IMAP now?
> 
> Because a sensible CAP server will be backed by a relational database,
> and should not be required to store blobs.

I do not see the correlation. If the iCalendar object contains
an inline attachment - are your going to throw it away?
--------------C3B5C87A852246BB3DA1D9A0
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------C3B5C87A852246BB3DA1D9A0--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 14:01:36 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21865
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:01:35 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AHrEg12560
	for ietf-calendar-bks; Tue, 10 Sep 2002 10:53:14 -0700 (PDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AHrDk12554
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:53:13 -0700 (PDT)
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AHrAe13816
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:53:10 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AHr0C13131
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:53:00 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AHqQO03473
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:52:26 -0600 (MDT)
Message-ID: <3D7E3159.17591799@oracle.com>
Date: Tue, 10 Sep 2002 13:52:25 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <3D7E10FE.B6D4C76D@oracle.com> <3D7E1E7F.BC74DD2B@Royer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Doug Royer wrote:
> 
> George Babics wrote:
> 
> >   I also agree that we need a compelling reason.
> >
> >   I feel that the simpler the better. Furthermore, we should
> > try to agree on a specific format rather than having multiple
> > possibilities. This will make co-existence much easier. (We
> > had interoperability problems during calconnect due to the
> > many different ways one can put an iCalendar into a MIME
> > object.)
> 
> MIME already specifies how a MIME objects are formed (and there
> is not one way). So do you mean with respect to VQUERY replies?
> As in how many VCALENDAR objects per MIME object? And how
> many MIME objects?

  Yes, with respect to replies.

> 
> Each text/calenendar MIME object is parsable now. If it
> contains one or multiple VCALENDAR objects and if it contains
> (or is part of) one or multiple body parts. What do we need to
> specify?

  We need to specify if we should use text/calendar or
multipart or some other format. If we allow for more than one,
it can lead to problems with interoperability.

> 
> If any iCalendar object is part of any MIME object, for the
> purpose of parsing and storing the iCalendar object, each
> text/calendar object is the root of its view. Start from
> that point and extract and store all CIDs and MIDs.
> If there are multiple text/calendar objects, each gets
> its view from its self. This is not unique to iCalendar.
> Its what MIME is. That's why they invented CID's and MIDs.
> 
> MIME and iCalendar allow for alternate representations now.
> If one CUA does not store all of it - that is fine. But
> I see no reason to break implementations when is all a CUA
> or CS has to do is ignore representations that it can not
> handle - and pass back a status code.

  Break what implementations? CAP is only a draft. At this
point we do not care about breaking implementations of CAP.

> 
> If a CUA or CS passes back an empty MULTIPART capability,
> then don't send it any and inform the user they need to
> select another vender or implementation. If that is something
> that some users will never use or need - fine.
> 
> > The only reason I see that one may want to support multipart is
> > for attachments. However, they can also be put inline into the
> > icalendar object.
> 
> That's implying that CAP needs to redefine 2445 and limit
> it to inline only.

No such implication was made. It simply stated that without multipart 
the only way to send attachments would be to send them inline.

George


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 14:15:04 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22300
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:15:04 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AI3at13070
	for ietf-calendar-bks; Tue, 10 Sep 2002 11:03:36 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AI3Yk13065
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:03:35 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091014121723422
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 14:12:17 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 14:01:53 -0400
Message-ID: <3D7E3391.3050703@centivinc.com>
Date: Tue, 10 Sep 2002 14:01:53 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris> <3D7E1A38.8090204@samsungcontact.com> <3D7E2346.1FFAE22C@Royer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 18:01:53.0674 (UTC) FILETIME=[250E16A0:01C258F4]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>Mark Davidson wrote:
>  
>
>>    
>>
>>If we allow multipart/related with URIs pointing to attachments, then
>>how do we get the data back out of the CS. If I do a search, then I
>>just get objects and properties.
>>
>
>SELECT * FROM VEVENT where UID = 'a-id'
>
>If it has inline attachments, they will be included.
>
Strawman alert: the question was about external attachments, not inline 
ones.

-- 
/===============================================================\
|John Stracke      |jstracke@centivinc.com                      |
|Principal Engineer|http://www.centivinc.com                    |
|Centiv            |My opinions are my own.                     |
|===============================================================|
|"Call me a Nervous Nellie, but I am concerned about the sale of|
|nuclear arms in my general neighborhood." -- Dave Barry        |
\===============================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 14:32:34 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22719
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:32:33 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AIFgw14860
	for ietf-calendar-bks; Tue, 10 Sep 2002 11:15:42 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AIFfk14854
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:15:41 -0700 (PDT)
In-Reply-To: <20020910152152.GE83146@inet.it>
To: Andrea Campi <a.campi@inet.it>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF52C92333.846AC5CB-ON85256C30.00606DA8-85256C30.0062EE3E@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 14:00:31 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 02:09:19 PM,
	Serialize complete at 09/10/2002 02:09:19 PM
Content-Type: multipart/alternative; boundary="=_alternative 0062EE3185256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0062EE3185256C30_=
Content-Type: text/plain; charset="US-ASCII"

Andrea replied on 09/10/2002 11:21:53 AM:
> You are right, and I agree with you that for ATTACHments to work we
> do need to support multipart. 

What about ALTREPs??

> What if we mandated that the reply to a SEARCH command (just to
> pick the most complex example) is contained in one or more VCALENDAR
> objects in the MIME root, and additional MIME parts can be sent
> for referenced ATTACHments? 

If the VCALENDAR (ie: text/calendar) entity _is_ the "MIME root" then you 
cannot have multiple MIME body parts in the same stream.  If the VCALENDAR 
entity _is_in_ the MIME root then sounds how iMIP requests are currently 
formulated (in the simplest format).  That is:

multipart/related
        text/calendar
        application/octet-stream

or possibly:

multipart/related
        multipart/alternative
                text/plain
                text/calendar
        application/octet-stream

(and so on).  In the 1st case the text/calendar is what some call the 
'root' entity.  In the 2nd case the multipart/alternative is the 'root' 
entity and the text/calendar is part of that entity. 

One thing to note is that only multipart/related (RFC 2387) actually 
defines the concept of a 'root' element; its not part of the base MIME 
RFCs where the other multipart subtypes are defined.  As such using the 
term 'MIME root' is only relevant w/in the scope of multipart/related 
discussions.

>                              Would this break any functionality?

I dont think so.

> Would this be against any RFC?

It would only against the RFCs if we violated the semantic meaning of the 
subtype really.  Ive yet to hear any suggestion that we misuse the 
subtypes but Im behind on my WG traffic.

So, if someone were to propose we send back data formatted like:

text/calendar
application/octet-stream

then Id say yes its a violation because we typed the top level MIME stream 
as text/calendar and followed it by an application /octet-stream.  This 
kind of data should have been enclosed in a multipart MIME wrapper.  As 
for which subtype Id say related over mixed or alternative given the 
semantics of each subtype.  From 2046:

5.1.3.  Mixed Subtype

   The "mixed" subtype of "multipart" is intended for use when the body
   parts are independent and need to be bundled in a particular order.

and since the parts are NOT independent this is not a proper choice. Also 
from 2046:

5.1.4.  Alternative Subtype

   The "multipart/alternative" type is syntactically identical to
   "multipart/mixed", but the semantics are different.  In particular,
   each of the body parts is an "alternative" version of the same
   information.

and since the iCalendar and attachment are NOT alternatives of each other 
this subtype is not the proper choice.  From 2387:

3.  Intended usage

   The Multipart/Related media type is intended for compound objects
   consisting of several inter-related body parts.  For a
   Multipart/Related object, proper display cannot be achieved by
   individually displaying the constituent body parts. 

so this seems to be the proper choice to use.  As we add alternative 
renderings (ie: ALTREPs) we have to increase the complexity of the MIME 
wrappering but the basic adherence to the intended usage of "related" is 
still adhered to.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0062EE3185256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Andrea replied on 09/10/2002 11:21:53 AM:<br>
&gt; You are right, and I agree with you that for ATTACHments to work we<br>
&gt; do need to support multipart. </tt></font>
<br>
<br><font size=2 face="sans-serif">What about ALTREPs??</font>
<br>
<br><font size=2><tt>&gt; What if we mandated that the reply to a SEARCH
command (just to<br>
&gt; pick the most complex example) is contained in one or more VCALENDAR<br>
&gt; objects in the MIME root, and additional MIME parts can be sent<br>
&gt; for referenced ATTACHments? </tt></font>
<br>
<br><font size=2 face="sans-serif">If the VCALENDAR (ie: text/calendar)
entity _<u>is</u>_ the &quot;MIME root&quot; then you cannot have multiple
MIME body parts in the same stream. &nbsp;If the VCALENDAR entity _<u>is_in</u>_
the MIME root then sounds how iMIP requests are currently formulated (in
the simplest format). &nbsp;That is:</font>
<br>
<br><font size=2 face="sans-serif">multipart/related</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; text/calendar</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; application/octet-stream</font>
<br>
<br><font size=2 face="sans-serif">or possibly:</font>
<br>
<br><font size=2 face="sans-serif">multipart/related</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; multipart/alternative</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; text/plain</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; text/calendar</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; application/octet-stream</font>
<br>
<br><font size=2 face="sans-serif">(and so on). &nbsp;In the 1st case the
text/calendar is what some call the 'root' entity. &nbsp;In the 2nd case
the multipart/alternative is the 'root' entity and the text/calendar is
part of that entity. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">One thing to note is that only multipart/related
(RFC 2387) actually defines the concept of a 'root' element; its not part
of the base MIME RFCs where the other multipart subtypes are defined. &nbsp;As
such using the term 'MIME root' is only relevant w/in the scope of multipart/related
discussions.</font>
<br>
<br><font size=2><tt>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Would this break
any functionality?<br>
</tt></font>
<br><font size=2 face="sans-serif">I dont think so.</font>
<br>
<br><font size=2><tt>&gt; Would this be against any RFC?<br>
</tt></font>
<br><font size=2 face="sans-serif">It would only against the RFCs if we
violated the semantic meaning of the subtype really. &nbsp;Ive yet to hear
any suggestion that we misuse the subtypes but Im behind on my WG traffic.</font>
<br>
<br><font size=2 face="sans-serif">So, if someone were to propose we send
back data formatted like:</font>
<br>
<br><font size=2 face="sans-serif">text/calendar</font>
<br><font size=2 face="sans-serif">application/octet-stream</font>
<br>
<br><font size=2 face="sans-serif">then Id say yes its a violation because
we typed the top level MIME stream as text/calendar and followed it by
an application /octet-stream. &nbsp;This kind of data should have been
enclosed in a multipart MIME wrapper. &nbsp;As for which subtype Id say
related over mixed or alternative given the semantics of each subtype.
&nbsp;From 2046:</font>
<br>
<br><font size=2><tt>5.1.3. &nbsp;Mixed Subtype<br>
<br>
 &nbsp; The &quot;mixed&quot; subtype of &quot;multipart&quot; is intended
for use when the body<br>
 &nbsp; parts are independent and need to be bundled in a particular order.<br>
</tt></font>
<br><font size=2 face="sans-serif">and since the parts are NOT independent
this is not a proper choice. &nbsp; Also from 2046:</font>
<br>
<br><font size=2><tt>5.1.4. &nbsp;Alternative Subtype<br>
<br>
 &nbsp; The &quot;multipart/alternative&quot; type is syntactically identical
to<br>
 &nbsp; &quot;multipart/mixed&quot;, but the semantics are different. &nbsp;In
particular,<br>
 &nbsp; each of the body parts is an &quot;alternative&quot; version of
the same<br>
 &nbsp; information.</tt></font>
<br>
<br><font size=2 face="sans-serif">and since the iCalendar and attachment
are NOT alternatives of each other this subtype is not the proper choice.
&nbsp;From 2387:</font>
<br>
<br><font size=2><tt>3. &nbsp;Intended usage<br>
<br>
 &nbsp; The Multipart/Related media type is intended for compound objects<br>
 &nbsp; consisting of several inter-related body parts. &nbsp;For a<br>
 &nbsp; Multipart/Related object, proper display cannot be achieved by<br>
 &nbsp; individually displaying the constituent body parts. </tt></font>
<br>
<br><font size=2 face="sans-serif">so this seems to be the proper choice
to use. &nbsp;As we add alternative renderings (ie: ALTREPs) we have to
increase the complexity of the MIME wrappering but the basic adherence
to the intended usage of &quot;related&quot; is still adhered to.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0062EE3185256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 14:33:05 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22785
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:33:04 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AIQvY16198
	for ietf-calendar-bks; Tue, 10 Sep 2002 11:26:57 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AIQtk16194
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:26:56 -0700 (PDT)
In-Reply-To: <3D7E1122.70716473@oracle.com>
To: George Babics <george.babics@oracle.com>
Cc: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OFF86E6429.D49EC96D-ON85256C30.00630521-85256C30.00653E91@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 14:25:47 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 02:20:34 PM,
	Serialize complete at 09/10/2002 02:20:34 PM
Content-Type: multipart/alternative; boundary="=_alternative 00653E8C85256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 00653E8C85256C30_=
Content-Type: text/plain; charset="US-ASCII"

George wrote on 09/10/2002 11:34:58 AM:
>   1) How can a CUA get all properties of a component except an
>      attachment, which may be very big?

Dont ask for the ATTACH property to be returned on the query??  Its 
unclear how to say "Only give me the VEVENT and no ATTACHments (or 
ALTREPs, etc)" but perhaps Doug or John can correct me and point this out.

Along the same vein of questioning: If the original ATTACHment is NOT 
inlined then is there any way for me to ask for the ATTACHments value but 
NOT the actual contents?  Also, is there any way for the CUA to tell 
apriori If the ATTACHment is inlined so it knows to ask the previous 
question instead of just saying "Dont give me any ATTACHments"?

>   2) How do we delete or modify an attachment if a component
>      has multiple attachments? 

Each ATTACHment must have a CID that is unique (unless you wanted to 
attach multiple copies of the same file!).  As such, you can uniquely 
identify them based on their CID value (sic).  As for updating/removing 
them, thats a total haze to me.  I can suggest ways that Ive seen it done 
for MHTML messages but those kinds of solutions basically involve resaving 
the entire stream and removing the old copy(s).  No "delta" operations 
there...

>                                CAP draft specifies that the
>      CUA can specify a part of the attachment such that it
>      is uniquely identified. That means that the CUA must download
>      the entire attachment, upload part of it in the MODIFY command,
>      and upload the entire new attachment. 

If the CUA has a local copy then it doesnt have to download it all to 
modify it.   If not then yes it has to download all, say, 25M of the file 
to modify it safely.  As for sending data back up its not clear that the 
entire updated ATTACHment must be sent back up.  If you can uniquely 
identify it via its CID then you could possibly just send the updates. 

Of course this could lead to some nasty/corrupted files if both you and 
your AA modify the same ZIP archive and dont actually have a way to detect 
that the 'original' copy has changed to a newer one (when the slower of 
the two of you try to do the MODIFY).  I strongly doubt you want to build 
in some kind of locking or checkout mechanism (ala WebDAV) into this or at 
least I hope not...  So whats the solution??...

>                                              How will the CUA know
>      up to now many bytes of the old attachment uniquely identifies
>      it.

Its not a function of the bytes you send back (or is it??); it should be a 
function of the CID.  If you allow CID reuse (ie: multiple ATTACHments of 
the same file and reuse of the CID thereof) then this wont work.  If you 
assigned a new CID per ATTACHment (even on duplicates) then you should be 
all set.

>   3) In section 9.5 (MODIFY Command):
> 
>         The ATTACHMENT value supplied by the CUA MUST BE
>         valid encoded information.
> 
>      What does this mean? Does it mean that the encoding must match
>      the "ENCODING" parameter? Can this always be verified?

Sounds like the its talking about the CID value of the ATTACH property. It 
could also be talking about an inlined ATTACHment where the data is all 
there and iCalendar has mandated particular property parameters be 
present.

I would hope that you dont allow an ATTACHment reference to a CID thats 
not available.  There may be a forward reference to a CID in the iCalendar 
data but once you scan the MIME stream you can tell if the CID is there or 
not.  If not, some consistant course of action should happen (ie: remove 
the ATTACH, send an error code to the CUA, etc).

>   4) How can a CUA let a user know that an event has an attachment
>      without downloading it? This can allow the attachment to be
>      downloaded only if the users "clicks" on it.

No clue how.  Id love to see a good way for the CUA to get info about 
ATTACHments (inlined or not) and have some way to do this...

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 00653E8C85256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>George wrote on 09/10/2002 11:34:58 AM:<br>
&gt; &nbsp; 1) How can a CUA get all properties of a component except an<br>
&gt; &nbsp; &nbsp; &nbsp;attachment, which may be very big?<br>
</tt></font>
<br><font size=2 face="sans-serif">Dont ask for the ATTACH property to
be returned on the query?? &nbsp;Its unclear how to say &quot;Only give
me the VEVENT and no ATTACHments (or ALTREPs, etc)&quot; but perhaps Doug
or John can correct me and point this out.</font>
<br>
<br><font size=2 face="sans-serif">Along the same vein of questioning:
If the original ATTACHment is NOT inlined then is there any way for me
to ask for the ATTACHments value but NOT the actual contents? &nbsp;Also,
is there any way for the CUA to tell apriori If the ATTACHment is inlined
so it knows to ask the previous question instead of just saying &quot;Dont
give me any ATTACHments&quot;?</font>
<br>
<br><font size=2><tt>&gt; &nbsp; 2) How do we delete or modify an attachment
if a component<br>
&gt; &nbsp; &nbsp; &nbsp;has multiple attachments? </tt></font>
<br>
<br><font size=2 face="sans-serif">Each ATTACHment must have a CID that
is unique (unless you wanted to attach multiple copies of the same file!).
&nbsp;As such, you can uniquely identify them based on their CID value
(sic). &nbsp;As for updating/removing them, thats a total haze to me. &nbsp;I
can suggest ways that Ive seen it done for MHTML messages but those kinds
of solutions basically involve resaving the entire stream and removing
the old copy(s). &nbsp;No &quot;delta&quot; operations there...</font>
<br>
<br><font size=2><tt>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;CAP draft
specifies that the<br>
&gt; &nbsp; &nbsp; &nbsp;CUA can specify a part of the attachment such
that it<br>
&gt; &nbsp; &nbsp; &nbsp;is uniquely identified. That means that the CUA
must download<br>
&gt; &nbsp; &nbsp; &nbsp;the entire attachment, upload part of it in the
MODIFY command,<br>
&gt; &nbsp; &nbsp; &nbsp;and upload the entire new attachment. <br>
</tt></font>
<br><font size=2 face="sans-serif">If the CUA has a local copy then it
doesnt have to download it all to modify it. &nbsp; If not then yes it
has to download all, say, 25M of the file to modify it safely. &nbsp;As
for sending data back up its not clear that the entire updated ATTACHment
must be sent back up. &nbsp;If you can uniquely identify it via its CID
then you could possibly just send the updates. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Of course this could lead to some nasty/corrupted
files if both you and your AA modify the same ZIP archive and dont actually
have a way to detect that the 'original' copy has changed to a newer one
(when the slower of the two of you try to do the MODIFY). &nbsp;I strongly
doubt you want to build in some kind of locking or checkout mechanism (ala
WebDAV) into this or at least I hope not... &nbsp;So whats the solution??...</font>
<br>
<br><font size=2><tt>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;How will the CUA know</tt></font>
<br><font size=2><tt>&gt; &nbsp; &nbsp; &nbsp;up to now many bytes of the
old attachment uniquely identifies<br>
&gt; &nbsp; &nbsp; &nbsp;it.<br>
</tt></font>
<br><font size=2 face="sans-serif">Its not a function of the bytes you
send back (or is it??); it should be a function of the CID. &nbsp;If you
allow CID reuse (ie: multiple ATTACHments of the same file and reuse of
the CID thereof) then this wont work. &nbsp;If you assigned a new CID per
ATTACHment (even on duplicates) then you should be all set.</font>
<br>
<br><font size=2><tt>&gt; &nbsp; 3) In section 9.5 (MODIFY Command):<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; The ATTACHMENT value supplied by the CUA
MUST BE<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; valid encoded information.<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp;What does this mean? Does it mean that the encoding
must match<br>
&gt; &nbsp; &nbsp; &nbsp;the &quot;ENCODING&quot; parameter? Can this always
be verified?<br>
</tt></font>
<br><font size=2 face="sans-serif">Sounds like the its talking about the
CID value of the ATTACH property. &nbsp;It could also be talking about
an inlined ATTACHment where the data is all there and iCalendar has mandated
particular property parameters be present.</font>
<br>
<br><font size=2 face="sans-serif">I would hope that you dont allow an
ATTACHment reference to a CID thats not available. &nbsp;There may be a
forward reference to a CID in the iCalendar data but once you scan the
MIME stream you can tell if the CID is there or not. &nbsp;If not, some
consistant course of action should happen (ie: remove the ATTACH, send
an error code to the CUA, etc).</font>
<br>
<br><font size=2><tt>&gt; &nbsp; 4) How can a CUA let a user know that
an event has an attachment<br>
&gt; &nbsp; &nbsp; &nbsp;without downloading it? This can allow the attachment
to be<br>
&gt; &nbsp; &nbsp; &nbsp;downloaded only if the users &quot;clicks&quot;
on it.<br>
</tt></font>
<br><font size=2 face="sans-serif">No clue how. &nbsp;Id love to see a
good way for the CUA to get info about ATTACHments (inlined or not) and
have some way to do this...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 00653E8C85256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 14:37:09 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22972
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:37:09 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AIU6C16314
	for ietf-calendar-bks; Tue, 10 Sep 2002 11:30:06 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AIU5k16310
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:30:05 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091014384832516
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 14:38:48 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 14:28:24 -0400
Message-ID: <3D7E39C8.8020303@centivinc.com>
Date: Tue, 10 Sep 2002 14:28:24 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF6CF961CE.CDA468FC-ON85256C2F.0053FF05-85256C2F.0059F96B@iris.com> <3D7CD1F3.1060201@centivinc.com> <3D7DBD7C.7070409@samsungcontact.com> <20020910102104.GD83146@inet.it> <3D7E138F.6648A937@Royer.com> <3D7E1FAC.3070504@centivinc.com> <3D7E2E51.BFBB6B05@Royer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 18:28:24.0756 (UTC) FILETIME=[D969EF40:01C258F7]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>John Stracke wrote:
>  
>
>>Doug Royer wrote:
>>
>>    
>>
>>>No one is saying that all CUA's must support multipart.
>>>We are saying that CUA's and CS's MAY support multipart.
>>>
>>>      
>>>
>>But MAYs and SHOULDs are a nightmare; they make interop incredibly hard,
>>and should be used only when totally unavoidable.
>>    
>>
>
>This debate has been going on for years. I think
>it is time to declare it unavoidable.
>
No.  It is time to stop throwing in extra options that add nothing.

-- 
/===========================================\
|John Stracke      |jstracke@centivinc.com  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|If you're omniscient, how do you know?     |
\===========================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 14:39:24 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23080
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:39:24 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AITdY16291
	for ietf-calendar-bks; Tue, 10 Sep 2002 11:29:39 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AITck16287
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:29:38 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091014382008916
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 14:38:20 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 14:27:56 -0400
Message-ID: <3D7E39AC.8060203@centivinc.com>
Date: Tue, 10 Sep 2002 14:27:56 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OFE9994917.ABBC0BBA-ON85256C30.0053D036-85256C30.0054F1E8@iris.com> <3D7E1DE7.7000003@centivinc.com> <3D7E2DF1.6B955F1@Royer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 18:27:56.0849 (UTC) FILETIME=[C8C7AA10:01C258F7]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>John Stracke wrote:
>  
>
>>Bruce_Kahn@notesdev.ibm.com wrote:
>>
>>    
>>
>>> (CAP is a 'superset' of iRIP which is a binding of iTIP so if you can
>>>do multipart in iTIP you can do it in the 'iRIP subset' of CAP...)
>>>      
>>>
>>You cannot do multipart in iTIP.
>>    
>>
>
>Where does it say that?
>
RFC-2446, Section 3:

   ITIP messages are "text/calendar" MIME entities that contain
   calendaring and scheduling information.

So an iTIP message cannot be a multipart/whatever containing a 
text/calendar; it *is* a text/calendar.

-- 
/===========================================\
|John Stracke      |jstracke@centivinc.com  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|If you're omniscient, how do you know?     |
\===========================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 14:44:08 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23243
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:44:07 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AIYVe16465
	for ietf-calendar-bks; Tue, 10 Sep 2002 11:34:31 -0700 (PDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AIYUk16461
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:34:30 -0700 (PDT)
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AIYR727390
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:34:27 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AIYRp27380
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:34:27 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AIYQv16141
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:34:26 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AIYPf16089
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:34:25 -0600 (MDT)
Message-ID: <3D7E3B30.2D2B9B7C@oracle.com>
Date: Tue, 10 Sep 2002 14:34:24 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <3D7E1122.70716473@oracle.com> <3D7E2DB2.284A9556@Royer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Doug Royer wrote:
> 
> George Babics wrote:
> >
> > [I sent this about an hour ago. It does not seem to have
> > gotten through. Perhaps my new e-mail address was recognized.
> > I resubscribed to the list with my new e-mail address.
> > Sorry if this message ends up appearing in duplicate.]
> >
> > A few questions about how to handle attachments:
> >
> >   1) How can a CUA get all properties of a component except an
> >      attachment, which may be very big?

      In other words, how can a small device avoid downloading
      attachments? It can formulate a query that specifies only
      the properties that it wants? Is this sufficient?

> 
> >   2) How do we delete or modify an attachment if a component
> >      has multiple attachments? CAP draft specifies that the
> >      CUA can specify a part of the attachment such that it
> >      is uniquely identified. That means that the CUA must download
> >      the entire attachment, upload part of it in the MODIFY command,
> >      and upload the entire new attachment. How will the CUA know
> >      up to now many bytes of the old attachment uniquely identifies
> >      it.
> 
> The ultimate purpose of an attachment is for the CU/CUA. So
> there is no way for a CU to know they wanted it modified, unless
> they have already have it downloaded or do the download. Ether
> way - it is going to have to be downloaded.

  What if the CUA simply wants to remove all the attachments?
Yes, it has to be downloaded (or maybe not, see #4 below).
However, to change it, it will have to download it, then upload it,
and upload another attachment. This can be expensive for inline
attachments.

  However, one may argue that inline attachment will be rare,
and people will usually use a URI. 

> 
> >   3) In section 9.5 (MODIFY Command):
> >
> >         The ATTACHMENT value supplied by the CUA MUST BE
> >         valid encoded information.
> >
> >      What does this mean? Does it mean that the encoding must match
> >      the "ENCODING" parameter? Can this always be verified?
> 
> The entire quote is:
> 
>    When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
>    identify the contents of the ATTACHMENT value in the old-values in
>    order to delete them.  When the CS compares the attachment data it is
>    compared in its binary form.  The ATTACHMENT value supplied by the
>    CUA MUST BE valid encoded information.
> 
> I think we can delete that last sentence as the comparison
> is done in its binary form.
> 
> 
> >   4) How can a CUA let a user know that an event has an attachment
> >      without downloading it? This can allow the attachment to be
> >      downloaded only if the users "clicks" on it.
> 
> So download it? Again - how the the CU know that is what
> they wanted to do without first knowing what it is?

  The CUA may want to be able to display to the user that
an event has an attachment without downloading it. If the CUA
displays a weekly view, it need not download all the attachments
for all the events in the view. What it may want to do, is to
display an icon in the event, to tell the user that the event has an
attachment. The attachment would only be downloaded if the user
opens the event, and then decides that he wants to see the attachment.

  In general, how can we avoid unnecessarily downloading an inline
attachment?

> 
> There is no requirement that just because a CUA gets an
> iCalendar object with a huge attachment, that the CUA must
> store it - the CU can reject it.

George


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 14:56:45 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21772
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:00:39 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AHg4511277
	for ietf-calendar-bks; Tue, 10 Sep 2002 10:42:04 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AHg3k11272
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:42:03 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AHg3bB011006
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 10:42:05 -0700
Message-ID: <3D7E2DF1.6B955F1@Royer.com>
Date: Tue, 10 Sep 2002 11:37:53 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OFE9994917.ABBC0BBA-ON85256C30.0053D036-85256C30.0054F1E8@iris.com> <3D7E1DE7.7000003@centivinc.com>
Content-Type: multipart/mixed;
 boundary="------------086F40C36865A5BF27FFEFD2"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------086F40C36865A5BF27FFEFD2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Stracke wrote:
> 
> Bruce_Kahn@notesdev.ibm.com wrote:
> 
> >  (CAP is a 'superset' of iRIP which is a binding of iTIP so if you can
> > do multipart in iTIP you can do it in the 'iRIP subset' of CAP...)
> 
> You cannot do multipart in iTIP.

Where does it say that?
--------------086F40C36865A5BF27FFEFD2
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------086F40C36865A5BF27FFEFD2--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 15:06:13 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23905
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 15:06:12 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AIx2r17170
	for ietf-calendar-bks; Tue, 10 Sep 2002 11:59:02 -0700 (PDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AIx1k17166
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:59:01 -0700 (PDT)
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AIwwe05952
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 11:58:58 -0700 (PDT)
Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AIwvC05916;
	Tue, 10 Sep 2002 11:58:57 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8AIwtN27455;
	Tue, 10 Sep 2002 12:58:55 -0600 (MDT)
Message-ID: <3D7E40EB.A227C71B@oracle.com>
Date: Tue, 10 Sep 2002 14:58:51 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: Bruce_Kahn@notesdev.ibm.com, ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
References: <OFF86E6429.D49EC96D-ON85256C30.00630521-85256C30.00653E91@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:
> 
> George wrote on 09/10/2002 11:34:58 AM:
> >   1) How can a CUA get all properties of a component except an
> >      attachment, which may be very big?
> 
> Dont ask for the ATTACH property to be returned on the query??  Its unclear how to say "Only give me the VEVENT and no ATTACHments (or ALTREPs, etc)" but perhaps Doug or John can correct me and
> point this out.
> 
> Along the same vein of questioning: If the original ATTACHment is NOT inlined then is there any way for me to ask for the ATTACHments value but NOT the actual contents?  Also, is there any way for
> the CUA to tell apriori If the ATTACHment is inlined so it knows to ask the previous question instead of just saying "Dont give me any ATTACHments"?
> 
> >   2) How do we delete or modify an attachment if a component
> >      has multiple attachments?
> 
> Each ATTACHment must have a CID that is unique (unless you wanted to attach multiple copies of the same file!).  As such, you can uniquely identify them based on their CID value (sic).  As for


  Attachments need not have a CID. When they are returned in MIME to the CUA
  they can have a CID. They also can be inline.


> updating/removing them, thats a total haze to me.  I can suggest ways that Ive seen it done for MHTML messages but those kinds of solutions basically involve resaving the entire stream and removing
> the old copy(s).  No "delta" operations there...
> 
> >                                CAP draft specifies that the
> >      CUA can specify a part of the attachment such that it
> >      is uniquely identified. That means that the CUA must download
> >      the entire attachment, upload part of it in the MODIFY command,
> >      and upload the entire new attachment.
> 
> If the CUA has a local copy then it doesnt have to download it all to modify it.   If not then yes it has to download all, say, 25M of the file to modify it safely.  As for sending data back up its
> not clear that the entire updated ATTACHment must be sent back up.  If you can uniquely identify it via its CID then you could possibly just send the updates.
> 
> Of course this could lead to some nasty/corrupted files if both you and your AA modify the same ZIP archive and dont actually have a way to detect that the 'original' copy has changed to a newer one
> (when the slower of the two of you try to do the MODIFY).  I strongly doubt you want to build in some kind of locking or checkout mechanism (ala WebDAV) into this or at least I hope not...  So whats
> the solution??...
> 
> >                                              How will the CUA know
> >      up to now many bytes of the old attachment uniquely identifies
> >      it.
> 
> Its not a function of the bytes you send back (or is it??); it should be a function of the CID.  If you allow CID reuse (ie: multiple ATTACHments of the same file and reuse of the CID thereof) then
> this wont work.  If you assigned a new CID per ATTACHment (even on duplicates) then you should be all set.
> 
> >   3) In section 9.5 (MODIFY Command):
> >
> >         The ATTACHMENT value supplied by the CUA MUST BE
> >         valid encoded information.
> >
> >      What does this mean? Does it mean that the encoding must match
> >      the "ENCODING" parameter? Can this always be verified?
> 
> Sounds like the its talking about the CID value of the ATTACH property.  It could also be talking about an inlined ATTACHment where the data is all there and iCalendar has mandated particular
> property parameters be present.
> 
> I would hope that you dont allow an ATTACHment reference to a CID thats not available.  There may be a forward reference to a CID in the iCalendar data but once you scan the MIME stream you can tell
> if the CID is there or not.  If not, some consistant course of action should happen (ie: remove the ATTACH, send an error code to the CUA, etc).
> 
> >   4) How can a CUA let a user know that an event has an attachment
> >      without downloading it? This can allow the attachment to be
> >      downloaded only if the users "clicks" on it.
> 
> No clue how.  Id love to see a good way for the CUA to get info about ATTACHments (inlined or not) and have some way to do this...
> 
> Bruce
> ===========================================================================
> Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
> Messaging & Collaboration                 Phone: 978.399.6496
> IBM Software Group                         FAX: and nothing but the FAX...
> Standard disclaimers apply, even where prohibited by law...


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 15:43:03 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25063
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 15:43:03 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8AJa2h18587
	for ietf-calendar-bks; Tue, 10 Sep 2002 12:36:02 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AJa0k18583
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:36:00 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AJa0bB011859
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:36:02 -0700
Message-ID: <3D7E48A5.4088B04D@Royer.com>
Date: Tue, 10 Sep 2002 13:31:49 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <3D7E10FE.B6D4C76D@oracle.com> <3D7E1E7F.BC74DD2B@Royer.com> <3D7E3159.17591799@oracle.com>
Content-Type: multipart/mixed;
 boundary="------------1B9B285CCD419CC74AC6BD7D"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


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

George Babics wrote:

>   We need to specify if we should use text/calendar or
> multipart or some other format. If we allow for more than one,
> it can lead to problems with interoperability.

The problems with iMIP interoperability is that some decided
not to fully support CIDs and MIDs and others did.

2445 Does not specify, so both are valid. So I think
in CAP we have to accomidate both.

> > If any iCalendar object is part of any MIME object, for the
> > purpose of parsing and storing the iCalendar object, each
> > text/calendar object is the root of its view. Start from
> > that point and extract and store all CIDs and MIDs.
> > If there are multiple text/calendar objects, each gets
> > its view from its self. This is not unique to iCalendar.
> > Its what MIME is. That's why they invented CID's and MIDs.
> >
> > MIME and iCalendar allow for alternate representations now.
> > If one CUA does not store all of it - that is fine. But
> > I see no reason to break implementations when is all a CUA
> > or CS has to do is ignore representations that it can not
> > handle - and pass back a status code.
> 
>   Break what implementations? CAP is only a draft. At this
> point we do not care about breaking implementations of CAP.

Break iCalendar implementations that already exist and
that already use multipart.

> > If a CUA or CS passes back an empty MULTIPART capability,
> > then don't send it any and inform the user they need to
> > select another vender or implementation. If that is something
> > that some users will never use or need - fine.
> >
> > > The only reason I see that one may want to support multipart is
> > > for attachments. However, they can also be put inline into the
> > > icalendar object.
> >
> > That's implying that CAP needs to redefine 2445 and limit
> > it to inline only.
> 
> No such implication was made. It simply stated that without multipart
> the only way to send attachments would be to send them inline.

There is no such restriction in 2445, so it would be a redefined.
--------------1B9B285CCD419CC74AC6BD7D
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------1B9B285CCD419CC74AC6BD7D--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 15:48:47 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25207
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 15:48:47 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AJdEL18692
	for ietf-calendar-bks; Tue, 10 Sep 2002 12:39:14 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AJdDk18688
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:39:13 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AJdCbB011874
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:39:16 -0700
Message-ID: <3D7E4965.D8F4D5CD@Royer.com>
Date: Tue, 10 Sep 2002 13:35:01 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris> <3D7E1A38.8090204@samsungcontact.com> <3D7E2346.1FFAE22C@Royer.com> <3D7E3391.3050703@centivinc.com>
Content-Type: multipart/mixed;
 boundary="------------C9B0A3CF879A764CAD6D148A"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------C9B0A3CF879A764CAD6D148A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Stracke wrote:
> 
> Doug Royer wrote:
> 
> >Mark Davidson wrote:
> >
> >
> >>
> >>
> >>If we allow multipart/related with URIs pointing to attachments, then
> >>how do we get the data back out of the CS. If I do a search, then I
> >>just get objects and properties.
> >>
> >
> >SELECT * FROM VEVENT where UID = 'a-id'
> >
> >If it has inline attachments, they will be included.
> >
> Strawman alert: the question was about external attachments, not inline
> ones.

No, it was about attachments inside the MIME multipart vs
inline in the same text/calendar.

Does anyone think that an attachment that is in another
MIME object (imap:, uri:, ...) should be inlined and
stored in the CS? I do not.
--------------C9B0A3CF879A764CAD6D148A
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------C9B0A3CF879A764CAD6D148A--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 15:55:33 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25349
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 15:55:33 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AJn7P18936
	for ietf-calendar-bks; Tue, 10 Sep 2002 12:49:07 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AJmXk18909
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:48:37 -0700 (PDT)
In-Reply-To: <3D7E1A38.8090204@samsungcontact.com>
To: Mark Davidson <markd@samsungcontact.com>
Cc: Andrea Campi <a.campi@inet.it>, ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF3E633E46.74E254CA-ON85256C30.00656DA7-85256C30.006CD01A@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 15:48:27 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 03:42:44 PM,
	Serialize complete at 09/10/2002 03:42:44 PM
Content-Type: multipart/alternative; boundary="=_alternative 006CD01685256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 006CD01685256C30_=
Content-Type: text/plain; charset="US-ASCII"

Mark Davidson <markd@samsungcontact.com> wrote on 09/10/2002 12:13:44 PM:
> I must admit, that because there was nothing about this in the 
> draft, I assumed that the CS just 
> stored URIs or encoded attachments. But I did forget about ALTREP.

Im glad that your (and possibly others) assumptions were noticed now 
rather than when we actually tried to code up CAP.  I know Im not immune 
either and Im sure others here will help keep me straight.

BTW: If the ATTACHments were just stored as URIs then it could be 
hard/impossible for someone on a different system to view the ATTACHment 
thats saved on my desktop.  I certainly wont open up my system to incoming 
requests for files and I know my company wont open up the firewall for 
Samsung users to get files from IBM users!  The ATTACHments should be with 
the entry in the MIME stream and the CS; the question is how they get here 
and how they are managed...

> But I still don't think multipart it the way to go.

ALTREP by definition implys multipart (and so does ATTACH).  If you dont 
allow for them you effectively remove those features from the standard.

> If we allow multipart/related with URIs pointing to attachments, 
> then how do we get the data back 
> out of the CS. If I do a search, then I just get objects and properties.

If you dont request for the ATTACH propery back then you wouldnt get it. 
This may work for ATTACHments but it wont work for ALTREPs since we have 
no way to say "Give me the DESCRIPTION of propery but NO ALTREPs if you 
got 'em." 

As such if you had a richer rendering of the DESCRIPTION your data being 
sent to the CUA should be something like:

multipart/related
        text/calendar
                ...
                DESCRIPTION;ALTREP=CID:12345.DESC@foo.org:CAP Design 
review\:
                ...
        text/html (Content-ID: 12345.DESC@foo.org)
                <HTML><HEAD><TITLE>CAP Meeting</TITLE></HEAD><BODY><P><H1>
                CAP Design review:</H1>
                ...

One approach is to say, "No richer renderings" but that too is a big step 
backwards. 

Another approach is to separate the iCalendar message from the ATTACHment 
and ALTREP data and provide a means to send the data between the CUA and 
CS (bidirectionally). 

Another possible approach is agree that multipart is "a necessary evil and 
the scourge on our efforts" but that we can design CAP so that its 
supported correctly but not necessarily thrust down someones throat.

> Either we need some commands for storing and retrieving attachments 
> in the CS, or we change search 
> to return multipart/related.

It is implicitly there already, its just not explicit nor is it clear. 
Thats one of my concerns. 

If you dont ask for the ATTACH property on your SEARCH, you certainly dont 
want/expect to get one back and the data will probably be just 
text/calendar (assuming no ALTREPs).  If you do ask for ATTACHments then 
you probably should get back some form of multipart...

Of course if your event has an alarm on it that you asked for and the 
alarm has a sound it should play you will probably get back multipart data 
there too...

> I would prefer some new commands and stick to text/icalendar as our 
> command format.

While it may be simpler to consider new commands that do essentially the 
same thing but that allow multipart data, it effectively means that we 
create duplicate command sets with the sole disctinction being that one 
set is for text/calendar MIME data only and the other is for multipart 
data.  This is interop hell in the making ("My CUA only dues multipart 
data and my CS only does plain iCalendar but both say they are CAP 
complaint.  Why wont they work together???", "Why dont my Alarm sounds 
play?")

Since you still have ALTREPs and ATTACHments to worry about and see plenty 
of uncertainty about how to deal with them in CAP I think that if we try 
we can come up with a single and consistant approach that everyone can 
live with that wont make implementing and interop testing a nightmare.  A 
solution is not unreachable, its just not currently obvious...

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 006CD01685256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Mark Davidson &lt;markd@samsungcontact.com&gt; wrote
on 09/10/2002 12:13:44 PM:<br>
&gt; I must admit, that because there was nothing about this in the <br>
&gt; draft, I assumed that the CS just <br>
&gt; stored URIs or encoded attachments. But I did forget about ALTREP.<br>
</tt></font>
<br><font size=2 face="sans-serif">Im glad that your (and possibly others)
assumptions were noticed now rather than when we actually tried to code
up CAP. &nbsp;I know Im not immune either and Im sure others here will
help keep me straight.</font>
<br>
<br><font size=2 face="sans-serif">BTW: If the ATTACHments were just stored
as URIs then it could be hard/impossible for someone on a different system
to view the ATTACHment thats saved on my desktop. &nbsp;I certainly wont
open up my system to incoming requests for files and I know my company
wont open up the firewall for Samsung users to get files from IBM users!
&nbsp;The ATTACHments should be with the entry in the MIME stream and the
CS; the question is how they get here and how they are managed...</font>
<br>
<br><font size=2><tt>&gt; But I still don't think multipart it the way
to go.<br>
</tt></font>
<br><font size=2 face="sans-serif">ALTREP by definition implys multipart
(and so does ATTACH). &nbsp;If you dont allow for them you effectively
remove those features from the standard.</font>
<br>
<br><font size=2><tt>&gt; If we allow multipart/related with URIs pointing
to attachments, <br>
&gt; then how do we get the data back <br>
&gt; out of the CS. If I do a search, then I just get objects and properties.<br>
</tt></font>
<br><font size=2 face="sans-serif">If you dont request for the ATTACH propery
back then you wouldnt get it. &nbsp;This may work for ATTACHments but it
wont work for ALTREPs since we have no way to say &quot;Give me the DESCRIPTION
of propery but NO ALTREPs if you got 'em.&quot; &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">As such if you had a richer rendering
of the DESCRIPTION your data being sent to the CUA should be something
like:</font>
<br>
<br><font size=2><tt>multipart/related</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; text/calendar</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; ...</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; DESCRIPTION;ALTREP=CID:12345.DESC@foo.org:CAP Design
review\:</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; ...</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; text/html (Content-ID:
12345.DESC@foo.org)</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &lt;HTML&gt;&lt;HEAD&gt;&lt;TITLE&gt;CAP Meeting&lt;/TITLE&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;H1&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; CAP Design review:&lt;/H1&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; ...</tt></font>
<br>
<br><font size=2 face="sans-serif">One approach is to say, &quot;No richer
renderings&quot; but that too is a big step backwards. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Another approach is to separate the
iCalendar message from the ATTACHment and ALTREP data and provide a means
to send the data between the CUA and CS (bidirectionally). &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Another possible approach is agree that
multipart is &quot;a necessary evil and the scourge on our efforts&quot;
but that we can design CAP so that its supported correctly but not necessarily
thrust down someones throat.</font>
<br>
<br><font size=2><tt>&gt; Either we need some commands for storing and
retrieving attachments <br>
&gt; in the CS, or we change search <br>
&gt; to return multipart/related.<br>
</tt></font>
<br><font size=2 face="sans-serif">It is implicitly there already, its
just not explicit nor is it clear. &nbsp;Thats one of my concerns. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">If you dont ask for the ATTACH property
on your SEARCH, you certainly dont want/expect to get one back and the
data will probably be just text/calendar (assuming no ALTREPs). &nbsp;If
you do ask for ATTACHments then you probably should get back some form
of multipart...</font>
<br>
<br><font size=2 face="sans-serif">Of course if your event has an alarm
on it that you asked for and the alarm has a sound it should play you will
probably get back multipart data there too...</font>
<br>
<br><font size=2><tt>&gt; I would prefer some new commands and stick to
text/icalendar as our <br>
&gt; command format.<br>
</tt></font>
<br><font size=2 face="sans-serif">While it may be simpler to consider
new commands that do essentially the same thing but that allow multipart
data, it effectively means that we create duplicate command sets with the
sole disctinction being that one set is for text/calendar MIME data only
and the other is for multipart data. &nbsp;This is interop hell in the
making (&quot;My CUA only dues multipart data and my CS only does plain
iCalendar but both say they are CAP complaint. &nbsp;Why wont they work
together???&quot;, &quot;Why dont my Alarm sounds play?&quot;)</font>
<br>
<br><font size=2 face="sans-serif">Since you still have ALTREPs and ATTACHments
to worry about and see plenty of uncertainty about how to deal with them
in CAP I think that if we try we can come up with a single and consistant
approach that everyone can live with that wont make implementing and interop
testing a nightmare. &nbsp;A solution is not unreachable, its just not
currently obvious...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 006CD01685256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 15:55:34 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25351
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 15:55:33 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AJmZ618914
	for ietf-calendar-bks; Tue, 10 Sep 2002 12:48:35 -0700 (PDT)
Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AJmXk18910
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 12:48:34 -0700 (PDT)
Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100])
	by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g8AJmUpf004106
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 15:48:31 -0400
Received: from c1271 (c-1271.in.steltor.com [101.1.46.9])
	by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id g8AJmRL26630
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 15:48:27 -0400 (EDT)
Message-ID: <024e01c25903$805f0500$092e0165@in.steltor.com>
From: "Graham Gilmore" <grahamg@steltor.com>
To: <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
Date: Tue, 10 Sep 2002 15:51:49 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Doug Royer wrote:
> John Stracke wrote:
> > They use multipart for iMIP.  An iMIP message will never be presented
> > directly to a CAP CS.
>
> Why not? Its a valid iCalendar object.
>
> > Instead, an MUA will accept the multipart,
> > extract the text/calendar body part, and submit it to the CS via CAP.
>
> Why? They are valid iCalendar objects.

    No, iMIP messages are MIME envelopes with specific characteristics.
iCalendar objects are the contents of those envelopes, being text in the
format defined by RFC 2445.  Just because iCalendar defines some specifics
as to how it should be enclosed in a MIME message (by specifying the MIME
type as "text/calendar", for example) doesn't make MIME part of iCalendar.
iCalendar says
*nothing* about external references (even within the same MIME envelope)
being considered part of the iCalendar object.

Doug Royer also wrote:
> Mark Davidson wrote:
> >
> > If we allow multipart/related with URIs pointing to attachments, then
> > how do we get the data back out of the CS. If I do a search, then I
> > just get objects and properties.
>
> SELECT * FROM VEVENT where UID = 'a-id'
>
> If it has inline attachments, they will be included. Where in
> CAP did it say that we only allow for some valid iCalendar objects?
> If your CUA could not support multipart, then you could not have
> put it into the CS. If your CUA can not support multipart and
> you contact a CS that is not yours, and the CS replies with
> a multipart message, then the CU has two choices, live with the
> error, or get another CUA.
>
> ATTACHMENTS are part of iCalendar as is ALTREP. If a CUA/CS does
> not wish to fully implement iCalendar - fine. But we can not
> mandate that no CUA or CS can fully implement iCalendar.

    Nowhere does it say that an CS must extract the contents referenced (for
example) by a cid: URI in an ATTACH property or a property with an ALTREP
parameter and store it along with the iCalendar data.
    As an illustration, RFC 2447 gives an interesting example:


4.1 Single Component With An ATTACH Property

   This minimal message shows how an iCalendar object references an
   attachment. The attachment is accessible via its URL.

   From: sman@netscape.com
   To: stevesil@microsoft.com
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:sman@netscape.com
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com
   ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T210000Z
   DTEND:19970701T230000Z
   SUMMARY:Phone Conference
   DESCRIPTION:Please review the attached document.
   UID:calsvr.example.com-873970198738777
   ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR


    Does this mean that to be a iCalendar-conformant CS, the CS must also
know how to retrieve files via FTP and store them?

    Specifying an ATTACH or ALTREP with a cid: is PERFECTLY VALID iCalendar,
I agree 100%.  However, expecting the CS to store & re-deliver to you at a
later time anything other than the URI that was in the original iCalendar is
ludicrous.  It is the CUA that must resolve the URI.  If you MUST have your
ATTACH stored in the CS, put it inline using the VALUE=BINARY parameter and
base64 encoding.
    Otherwise, not only do you have to store the iCalendar, but you have to
store all the MIME envelopes for all CAP messages as well just in case
someone decides to include a cid: URI to the ATTACH they included with a
meeting 6 years ago (oh, did your CS clean up that old data already?  oops!)

    Graham





From owner-ietf-calendar@mail.imc.org  Tue Sep 10 16:14:03 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25699
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 16:14:02 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AK35819541
	for ietf-calendar-bks; Tue, 10 Sep 2002 13:03:05 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AK33k19537
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:03:03 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AK30bB012054
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:03:05 -0700
Message-ID: <3D7E4EF9.347E75E8@Royer.com>
Date: Tue, 10 Sep 2002 13:58:49 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <OFF86E6429.D49EC96D-ON85256C30.00630521-85256C30.00653E91@iris.com>
Content-Type: multipart/mixed;
 boundary="------------05ED084D8D831F0A0D8BD1F2"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------05ED084D8D831F0A0D8BD1F2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce_Kahn@notesdev.ibm.com wrote:
> 
> George wrote on 09/10/2002 11:34:58 AM:
> >   1) How can a CUA get all properties of a component except an
> >      attachment, which may be very big?
> 
> Dont ask for the ATTACH property to be returned on the query??  Its
> unclear how to say "Only give me the VEVENT and no ATTACHments (or
> ALTREPs, etc)" but perhaps Doug or John can correct me and point this
> out.

Correct - We do not have an exclude mechanism.

> Along the same vein of questioning: If the original ATTACHment is NOT
> inlined then is there any way for me to ask for the ATTACHments value
> but NOT the actual contents?  Also, is there any way for the CUA to
> tell apriori If the ATTACHment is inlined so it knows to ask the
> previous question instead of just saying "Dont give me any
> ATTACHments"?

Correct, you can query for a parameter (it value), however we have no
way to restrict the size of the contents of the attachment (outside of
SIZE capabilities). And there is no way to tell in advance if
it is a URI or inlined encoded data. And there is no way without
querying for the the ATTACH value to tell if the ATTACH points outside
or inside of the CS.

The reason for inline attachments was to allow for small
attachments. The reason for MIME body part attachments
was to allow for multiple CID/MID links and not force
replication of the data especially then the attachments are
huge, and to allow for huge attachments.

There are CELL phones now that do video. Why not cell
calendar entries that have huge attachments?

> >   2) How do we delete or modify an attachment if a component
> >      has multiple attachments?
> 
> Each ATTACHment must have a CID that is unique (unless you wanted to
> attach multiple copies of the same file!).  As such, you can uniquely
> identify them based on their CID value (sic).  As for
> updating/removing them, thats a total haze to me.  I can suggest ways
> that Ive seen it done for MHTML messages but those kinds of solutions
> basically involve resaving the entire stream and removing the old
> copy(s).  No "delta" operations there...

We allow the CUA to send down all or just what uniquely identifies
the attachment for removal or modification. It is not relevant
to the protocol if the attachment in inlined or not, it is just
required to be in the CS.

> ...Of course this could lead to some nasty/corrupted files if both you
> and your AA modify the same ZIP archive and dont actually have a way
> to detect that the 'original' copy has changed to a newer one (when
> the slower of the two of you try to do the MODIFY).  I strongly doubt
> you want to build in some kind of locking or checkout mechanism (ala
> WebDAV) into this or at least I hope not...  So whats the
> solution??...

I think this falls into we do not specify transactional
integrity in CAP. We have explicitly limited CAP in this
way - per the Dallas meeting which formulated the CAP
requirements document.

> >                                              How will the CUA know
> >      up to now many bytes of the old attachment uniquely identifies
> >      it.
> 
> Its not a function of the bytes you send back (or is it??); it should
> be a function of the CID.  If you allow CID reuse (ie: multiple
> ATTACHments of the same file and reuse of the CID thereof) then this
> wont work.  If you assigned a new CID per ATTACHment (even on
> duplicates) then you should be all set.

We allow them to specify just what they want to change. And yes,
if the attachment is a URI, they can just change the URI value.

> >   3) In section 9.5 (MODIFY Command):
> >
> >         The ATTACHMENT value supplied by the CUA MUST BE
> >         valid encoded information.
> >
> >      What does this mean? Does it mean that the encoding must match
> >      the "ENCODING" parameter? Can this always be verified?
> 
> Sounds like the its talking about the CID value of the ATTACH
> property.  It could also be talking about an inlined ATTACHment where
> the data is all there and iCalendar has mandated particular property
> parameters be present.

Also the data. I don't see that is is relevant to the protocol.
If the attachment is inlined or in a separate body part. In both
cases you send what is unique to the data.

If you were to say:

	SELECT ATTACH from VEVENT where uid='1'

I could expect a MIME object with 2 body parts, one being
the REPLY, the other being the attachment. Or one (the REPLY)
with an inline attachment. Both are valid iCalendar objects.

> I would hope that you dont allow an ATTACHment reference to a CID
> thats not available.  There may be a forward reference to a CID in the
> iCalendar data but once you scan the MIME stream you can tell if the
> CID is there or not.  If not, some consistant course of action should
> happen (ie: remove the ATTACH, send an error code to the CUA, etc).

CIDs to non-CAP external attachments are allowed, (IMAP: for example).
We and 2445 have no such restriction. So the only checking could be
for MIME object that are inline or packaged in the same MIME object
could be checked.

> >   4) How can a CUA let a user know that an event has an attachment
> >      without downloading it? This can allow the attachment to be
> >      downloaded only if the users "clicks" on it.
> 
> No clue how.  Id love to see a good way for the CUA to get info about
> ATTACHments (inlined or not) and have some way to do this...

Looking for proposals :-)
--------------05ED084D8D831F0A0D8BD1F2
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------05ED084D8D831F0A0D8BD1F2--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 16:14:07 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25713
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 16:14:07 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AK5KT19596
	for ietf-calendar-bks; Tue, 10 Sep 2002 13:05:20 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AK4xk19582
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:05:04 -0700 (PDT)
In-Reply-To: <3D7E10FE.B6D4C76D@oracle.com>
To: George Babics <george.babics@oracle.com>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF681C4982.6CB3AAE3-ON85256C30.006CD83F-85256C30.006E4AAE@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 16:04:36 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 03:58:53 PM,
	Serialize complete at 09/10/2002 03:58:53 PM
Content-Type: multipart/alternative; boundary="=_alternative 006E4AAA85256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 006E4AAA85256C30_=
Content-Type: text/plain; charset="US-ASCII"

George replied on 09/10/2002 11:34:22 AM:
>   I feel that the simpler the better. Furthermore, we should
> try to agree on a specific format rather than having multiple
> possibilities. This will make co-existence much easier. (We
> had interoperability problems during calconnect due to the
> many different ways one can put an iCalendar into a MIME
> object.)

I think that being more explicit in CAP WRT multipart data is something we 
mostly agree on.  I think that having 10+ different ways to represent the 
same data is going to lead us to another interop nightmare with different 
implementors taking different approaches to represent the same data and 
neither is 'compatable'.

Part of the multipart issues are previous CalConnects was that some 
vendors didnt support it at all (nor did they support ALTREP and ATTACH; 
they simply ignored them).  Others did but in different ways or only 
partially.  We should learn from this and correct the issue in CAP before 
we RFC, not repeat it because noone wants to face the issues!

>   The only reason I see that one may want to support multipart is
> for attachments. However, they can also be put inline into the
> icalendar object. 

What about ALTREPs?

I personally think that putting ATTACHments inline is a poor idea. 
Frank/Derik added that relatively late in the game with the intent that it 
was intended for small amounts of data; not for massive 1M or larger 
attachments.  I for one would love to be rid of inline data as it requires 
my iCalendar parser to scan and parse data that the it really shouldnt 
care about.  Its much faster to parse the text/calendar block and render 
it if I dont have to parse over (or skip over) inlined binary...

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 006E4AAA85256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>George replied on 09/10/2002 11:34:22 AM:<br>
&gt; &nbsp; I feel that the simpler the better. Furthermore, we should<br>
&gt; try to agree on a specific format rather than having multiple<br>
&gt; possibilities. This will make co-existence much easier. (We<br>
&gt; had interoperability problems during calconnect due to the<br>
&gt; many different ways one can put an iCalendar into a MIME<br>
&gt; object.)<br>
</tt></font>
<br><font size=2 face="sans-serif">I think that being more explicit in
CAP WRT multipart data is something we mostly agree on. &nbsp;I think that
having 10+ different ways to represent the same data is going to lead us
to another interop nightmare with different implementors taking different
approaches to represent the same data and neither is 'compatable'.</font>
<br>
<br><font size=2 face="sans-serif">Part of the multipart issues are previous
CalConnects was that some vendors didnt support it at all (nor did they
support ALTREP and ATTACH; they simply ignored them). &nbsp;Others did
but in different ways or only partially. &nbsp;We should learn from this
and correct the issue in CAP before we RFC, not repeat it because noone
wants to face the issues!</font>
<br>
<br><font size=2><tt>&gt; &nbsp; The only reason I see that one may want
to support multipart is<br>
&gt; for attachments. However, they can also be put inline into the<br>
&gt; icalendar object. <br>
</tt></font>
<br><font size=2 face="sans-serif">What about ALTREPs?</font>
<br>
<br><font size=2 face="sans-serif">I personally think that putting ATTACHments
inline is a poor idea. &nbsp;Frank/Derik added that relatively late in
the game with the intent that it was intended for small amounts of data;
not for massive 1M or larger attachments. &nbsp;I for one would love to
be rid of inline data as it requires my iCalendar parser to scan and parse
data that the it really shouldnt care about. &nbsp;Its much faster to parse
the text/calendar block and render it if I dont have to parse over (or
skip over) inlined binary...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 006E4AAA85256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 16:29:40 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25958
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 16:29:40 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AKIhU20083
	for ietf-calendar-bks; Tue, 10 Sep 2002 13:18:43 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AKIfk20078
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:18:42 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AKIgbB012170
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:18:44 -0700
Message-ID: <3D7E52A6.2456F82C@Royer.com>
Date: Tue, 10 Sep 2002 14:14:30 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <3D7E1122.70716473@oracle.com> <3D7E2DB2.284A9556@Royer.com> <3D7E3B30.2D2B9B7C@oracle.com>
Content-Type: multipart/mixed;
 boundary="------------681135FFEF5B4466D3E486DD"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------681135FFEF5B4466D3E486DD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

George Babics wrote:

> > >
> > > A few questions about how to handle attachments:
> > >
> > >   1) How can a CUA get all properties of a component except an
> > >      attachment, which may be very big?
> 
>       In other words, how can a small device avoid downloading
>       attachments? It can formulate a query that specifies only
>       the properties that it wants? Is this sufficient?

I seem to recall that we had this debate before, and concluded
that it was sufficient.

> >
> > >   2) How do we delete or modify an attachment if a component
> > >      has multiple attachments? CAP draft specifies that the
> > >      CUA can specify a part of the attachment such that it
> > >      is uniquely identified. That means that the CUA must download
> > >      the entire attachment, upload part of it in the MODIFY command,
> > >      and upload the entire new attachment. How will the CUA know
> > >      up to now many bytes of the old attachment uniquely identifies
> > >      it.
> >
> > The ultimate purpose of an attachment is for the CU/CUA. So
> > there is no way for a CU to know they wanted it modified, unless
> > they have already have it downloaded or do the download. Ether
> > way - it is going to have to be downloaded.
> 
>   What if the CUA simply wants to remove all the attachments?
> Yes, it has to be downloaded (or maybe not, see #4 below).
> However, to change it, it will have to download it, then upload it,
> and upload another attachment. This can be expensive for inline
> attachments.

The delete and modification phase only has to download whatever
makes it unique, not the entire attachment. I would think
that that is going to be relativity small.

If you are modifying it, yes you will have to send down
what you want the new value to become.

If it is external to the CS (an FTP attachment for example),
then the modification is going to fail.

>   However, one may argue that inline attachment will be rare,
> and people will usually use a URI.

I don't think we can make that assumption. Some on this
list seem to be debating for inline only.

Ether case, it does not matter to the protocol. In both
cases if they are part of the calendar object, then they
will both be in the CS no matter how they were transferred.

> > >   4) How can a CUA let a user know that an event has an attachment
> > >      without downloading it? This can allow the attachment to be
> > >      downloaded only if the users "clicks" on it.
> >
> > So download it? Again - how the the CU know that is what
> > they wanted to do without first knowing what it is?
> 
>   The CUA may want to be able to display to the user that
> an event has an attachment without downloading it. If the CUA
> displays a weekly view, it need not download all the attachments
> for all the events in the view. What it may want to do, is to
> display an icon in the event, to tell the user that the event has an
> attachment. The attachment would only be downloaded if the user
> opens the event, and then decides that he wants to see the attachment.
> 
>   In general, how can we avoid unnecessarily downloading an inline
> attachment?

For an inline attachment (from 2445):

     ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
      MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
      EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
        <...remainder of "BASE64" encoded binary data...>

   The VALUE will be BINARY and it will have a known ENCODING.

For an FTP attachment (from 2445):

     ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud
 
   The VALUE TYPE is URI (the default) and the ATTACH value
   will start with 'ftp:'. Similar to an HTTP attachment.

For a CID attachment (from 2445):

     ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com

   The VALUE TYPE is URI (the default) and the ATTACH value
   will start with 'CID:'.

So I guess you could query for the VALUE from ATTACH and
look at the results. If the VALUE is BINARY, then it is inline
to the iCalendar object, else it is in another body part, or
external to the CS.
--------------681135FFEF5B4466D3E486DD
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------681135FFEF5B4466D3E486DD--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 16:38:30 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26162
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 16:38:29 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AKYAi20493
	for ietf-calendar-bks; Tue, 10 Sep 2002 13:34:10 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AKY9k20489
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:34:09 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AKY8bB012310
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:34:11 -0700
Message-ID: <3D7E5644.A0B3F9B9@Royer.com>
Date: Tue, 10 Sep 2002 14:29:56 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <024e01c25903$805f0500$092e0165@in.steltor.com>
Content-Type: multipart/mixed;
 boundary="------------79A3D760A384B842FBDB1812"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------79A3D760A384B842FBDB1812
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Graham Gilmore wrote:
> 
> Doug Royer wrote:
> > John Stracke wrote:
> > > They use multipart for iMIP.  An iMIP message will never be presented
> > > directly to a CAP CS.
> >
> > Why not? Its a valid iCalendar object.
> >
> > > Instead, an MUA will accept the multipart,
> > > extract the text/calendar body part, and submit it to the CS via CAP.
> >
> > Why? They are valid iCalendar objects.
> 
>     No, iMIP messages are MIME envelopes with specific characteristics.
> iCalendar objects are the contents of those envelopes, being text in the
> format defined by RFC 2445.

Which include ALTREP and ATTACH.

> ...
--------------79A3D760A384B842FBDB1812
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------79A3D760A384B842FBDB1812--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 16:57:44 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26399
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 16:57:43 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AKk0h21103
	for ietf-calendar-bks; Tue, 10 Sep 2002 13:46:00 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AKjxk21098
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:45:59 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8AKjxbB012403
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 13:46:02 -0700
Message-ID: <3D7E590B.C7A10CC4@Royer.com>
Date: Tue, 10 Sep 2002 14:41:47 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <024e01c25903$805f0500$092e0165@in.steltor.com>
Content-Type: multipart/mixed;
 boundary="------------D1F1C01C234D06A6CB799B13"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------D1F1C01C234D06A6CB799B13
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> Nowhere does it say that an CS must extract the contents referenced (for
> example) by a cid: URI in an ATTACH property or a property with an ALTREP
> parameter and store it along with the iCalendar data.

Again - some iMIP implementations can only process text/calendar
as the only  body part. That does not mean that we must restrict
CAP to those implementations.

> As an illustration, RFC 2447 gives an interesting example:
> ...
> Does this mean that to be a iCalendar-conformant CS, the CS
> must also know how to retrieve files via FTP and store them?

No. Not unless it is in the same MIME object (and FTP is not).

>  Specifying an ATTACH or ALTREP with a cid: is PERFECTLY VALID
> iCalendar, I agree 100%.  However, expecting the CS to store &
> re-deliver to you at a later time anything other than the URI that
> was in the original iCalendar is ludicrous.  It is the CUA that must
> resolve the URI.  If you MUST have your ATTACH stored in the CS, put
> it inline using the VALUE=BINARY parameter and base64 encoding.

What if the URI is a CID to a body part in the same
MIME object ? - What then do you expect it to retrieve?
Nothing? Again, not all CSs or CUAs need implement the
storage for all of the iCalendar object. Some implementations
can't do recurrence rules - you get an error.

> Otherwise, not only do you have to store the iCalendar, but you have
> to store all the MIME envelopes for all CAP messages as well just in
> case someone decides to include a cid: URI to the ATTACH they included
> with a meeting 6 years ago (oh, did your CS clean up that old data
> already?  oops!)

If you still have the component and the attachment was sent to
you inline - what do you expect to do? How will you decide
to clean those up? It is the same issue. We are NOT mandating
how the CS stores data. We are NOT mandating any cleanup.

We have provided commands so the CU/CUA can decide what to
and when to delete. The CU/CUA can delete components, or
properties from components, or paramaters from properties.
The policy is up to the CU/CUA.
--------------D1F1C01C234D06A6CB799B13
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------D1F1C01C234D06A6CB799B13--



From owner-ietf-calendar@mail.imc.org  Tue Sep 10 17:18:56 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26798
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 17:18:55 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8ALEGP23281
	for ietf-calendar-bks; Tue, 10 Sep 2002 14:14:16 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8ALEFk23277
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 14:14:15 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091017225803094
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 17:22:58 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 17:12:34 -0400
Message-ID: <3D7E6043.90107@centivinc.com>
Date: Tue, 10 Sep 2002 17:12:35 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <024e01c25903$805f0500$092e0165@in.steltor.com> <3D7E590B.C7A10CC4@Royer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 21:12:34.0744 (UTC) FILETIME=[C876D380:01C2590E]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>>Nowhere does it say that an CS must extract the contents referenced (for
>>example) by a cid: URI in an ATTACH property or a property with an ALTREP
>>parameter and store it along with the iCalendar data.
>>    
>>
>
>Again - some iMIP implementations can only process text/calendar
>as the only  body part.
>
Those are not iMIP implementations.  An iMIP implementation must be a 
MIME MUA, and a MIME MUA must support multipart.

But a CAP CUA is not a MIME MUA.

>>As an illustration, RFC 2447 gives an interesting example:
>>...
>>Does this mean that to be a iCalendar-conformant CS, the CS
>>must also know how to retrieve files via FTP and store them?
>>    
>>
>
>No. Not unless it is in the same MIME object (and FTP is not).
>
So why is MIME privileged? Why must a CUA support cid: and not ftp:? 
There's nothing in iCalendar to require it.

-- 
/=============================================================\
|John Stracke      |jstracke@centivinc.com                    |
|Principal Engineer|http://www.centivinc.com                  |
|Centiv            |My opinions are my own.                   |
|=============================================================|
|"The Elliot 903 was the first portable I ever used, though it|
|needed a furniture van to *make* it portable." --Will Rose   |
\=============================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 17:25:54 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26981
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 17:25:53 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AL5d322988
	for ietf-calendar-bks; Tue, 10 Sep 2002 14:05:39 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8AL5bk22984
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 14:05:38 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091017142108725
 for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 17:14:21 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 10 Sep 2002 17:03:57 -0400
Message-ID: <3D7E5E3E.5010408@centivinc.com>
Date: Tue, 10 Sep 2002 17:03:58 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <024e01c25903$805f0500$092e0165@in.steltor.com> <3D7E5644.A0B3F9B9@Royer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Sep 2002 21:03:57.0164 (UTC) FILETIME=[93F662C0:01C2590D]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>Graham Gilmore wrote:
>  
>
>>Doug Royer wrote:
>>    
>>
>>>John Stracke wrote:
>>>      
>>>
>>>>They use multipart for iMIP.  An iMIP message will never be presented
>>>>directly to a CAP CS.
>>>>        
>>>>
>>>Why not? Its a valid iCalendar object.
>>>
>>>      
>>>
>>>>Instead, an MUA will accept the multipart,
>>>>extract the text/calendar body part, and submit it to the CS via CAP.
>>>>        
>>>>
>>>Why? They are valid iCalendar objects.
>>>      
>>>
>>    No, iMIP messages are MIME envelopes with specific characteristics.
>>iCalendar objects are the contents of those envelopes, being text in the
>>format defined by RFC 2445.
>>    
>>
>
>Which include ALTREP and ATTACH.
>
>  
>
Requiring that the CS store ALTREP and ATTACH does not mean requiring it 
to store what they point to.

-- 
/=============================================================\
|John Stracke      |jstracke@centivinc.com                    |
|Principal Engineer|http://www.centivinc.com                  |
|Centiv            |My opinions are my own.                   |
|=============================================================|
|"The Elliot 903 was the first portable I ever used, though it|
|needed a furniture van to *make* it portable." --Will Rose   |
\=============================================================/




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 17:48:33 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27467
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 17:48:32 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8ALXVm23805
	for ietf-calendar-bks; Tue, 10 Sep 2002 14:33:31 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ALXTk23801
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 14:33:29 -0700 (PDT)
To: John Stracke <jstracke@centivinc.com>
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OF6985B148.27E8221F-ON85256C30.00711938-85256C30.00766634@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Tue, 10 Sep 2002 17:33:10 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/10/2002 05:27:07 PM,
	Serialize complete at 09/10/2002 05:27:07 PM
Content-Type: multipart/alternative; boundary="=_alternative 0076662B85256C30_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0076662B85256C30_=
Content-Type: text/plain; charset="US-ASCII"

John wrote:
> >It has been a while so maybe it is multipart/mixed that I mean.
> >
> >Is multipart/related when you have the first part that can
> >contain CID's or MID's?
> >
> Yes.

Not strictly true.  Its possible to have CID/MID references in subparts of 
the multipart/related.  For example:

multipart/related
        multipart/alternative
                text/plain
                text/html
                application/ms-tnef
        image/gif
        image/gif

where the CID references are in the text/html or possibly the 
application/ms-tnef.

> >DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
> >       XYZ Review Meeting will include the following agenda items: (a)
> >       Market Overview, (b) Finances, (c) Project Management
> >
> >   ...
> >
> >
> >So multipart/<something> must be valid.
> >
> Not necessarily.  A cid: URL can point to a body-part outside the 
> current message (see RFC-2392, section 1, paragraph 3).

Yes, thats allowed but not the normal/expected usage.  MTHML message tend 
to include the content in other body parts and the examples in RFC 2392 
use CIDs to point to other body parts in the same stream and MIDs to point 
to messages. 

Still, unless you can 100% guarantee that the externally referenced CID is 
still around and accesable by every CU then its very unsafe to just assume 
that you can use a CID to an ATTACHment or ALTREP that was sent out a 
while ago.  (If I didnt get the initial invitation then I certainly wont 
have the CID from it for you to refer to later on.)

I delete lots of older mail/docs/invites when newer ones arrive; otherwise 
my mail file would be much much larger than the 500M+ it is now.  I may be 
an anomoly but I know that many of our users dont keep 'older' copies of 
requests and the like around so Im not that unusual.

Also, unless you are advocating the return to 'deltas' in iCalendar you 
want/need to be sending full snapshots to invitees.  As such, since the 
ATTACHment and ALTREPs are part of that snapshot you should be resending 
them.

When referring to RFC 2392 you need to take into account that it was 
designed around the mail store which is NOT typically shared per user. 
That is, you cannot send me a CID that refers to a body part in a message 
in Dougs message store/calendar (even on the same CS).

Actually you could send it but I would certainly hope that your CS would 
prevent me from getting it (I certainly dont let everyone have direct 
access to my calendar!).  The CS is not logically equivalent to "the 
message store" from 2392; the calendar is.

The gist of all this is that yes a CID can refer to a body part in another 
message but A) its not safe to assume that everyone has that CID (for 
several reasons), B) the "message store" of RFC 2392 is not logically 
equivalent to the CS and C) the data the CID referneces still has to find 
some way to get to the CS and Ive yet to hear how you thinks that will 
happen.

Bruce
==========
=================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0076662B85256C30_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>John wrote:<br>
&gt; &gt;It has been a while so maybe it is multipart/mixed that I mean.<br>
&gt; &gt;<br>
&gt; &gt;Is multipart/related when you have the first part that can<br>
&gt; &gt;contain CID's or MID's?<br>
&gt; &gt;<br>
&gt; Yes.<br>
</tt></font>
<br><font size=2 face="sans-serif">Not strictly true. &nbsp;Its possible
to have CID/MID references in subparts of the multipart/related. &nbsp;For
example:</font>
<br>
<br><font size=2 face="sans-serif">multipart/related</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; multipart/alternative</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; text/plain</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; text/html</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; application/ms-tnef</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; image/gif</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; image/gif</font>
<br>
<br><font size=2 face="sans-serif">where the CID references are in the
text/html or possibly the application/ms-tnef.</font>
<br>
<br><font size=2><tt>&gt; &gt;DESCRIPTION;ALTREP=&quot;CID:&lt;part3.msg.970415T083000@host.com&gt;&quot;:Project<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; XYZ Review Meeting will include the following
agenda items: (a)<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; Market Overview, (b) Finances, (c) Project
Management<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; ...<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;So multipart/&lt;something&gt; must be valid.<br>
&gt; &gt;<br>
&gt; Not necessarily. &nbsp;A cid: URL can point to a body-part outside
the <br>
&gt; current message (see RFC-2392, section 1, paragraph 3).<br>
</tt></font>
<br><font size=2 face="sans-serif">Yes, thats allowed but not the normal/expected
usage. &nbsp;MTHML message tend to include the content in other body parts
and the examples in RFC 2392 use CIDs to point to other body parts in the
same stream and MIDs to point to messages. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Still, unless you can 100% guarantee
that the externally referenced CID is still around and accesable by every
CU then its very unsafe to just assume that you can use a CID to an ATTACHment
or ALTREP that was sent out a while ago. &nbsp;(If I didnt get the initial
invitation then I certainly wont have the CID from it for you to refer
to later on.)</font>
<br>
<br><font size=2 face="sans-serif">I delete lots of older mail/docs/invites
when newer ones arrive; otherwise my mail file would be much much larger
than the 500M+ it is now. &nbsp;I may be an anomoly but I know that many
of our users dont keep 'older' copies of requests and the like around so
Im not that unusual.</font>
<br>
<br><font size=2 face="sans-serif">Also, unless you are advocating the
return to 'deltas' in iCalendar you want/need to be sending full snapshots
to invitees. &nbsp;As such, since the ATTACHment and ALTREPs are part of
that snapshot you should be resending them.</font>
<br>
<br><font size=2 face="sans-serif">When referring to RFC 2392 you need
to take into account that it was designed around the mail store which is
NOT typically shared per user. &nbsp;That is, you cannot send me a CID
that refers to a body part in a message in Dougs message store/calendar
(even on the same CS).</font>
<br>
<br><font size=2 face="sans-serif">Actually you could send it but I would
certainly hope that your CS would prevent me from getting it (I certainly
dont let everyone have direct access to my calendar!). &nbsp;The CS is
not logically equivalent to &quot;the message store&quot; from 2392; the
calendar is.</font>
<br>
<br><font size=2 face="sans-serif">The gist of all this is that yes a CID
can refer to a body part in another message but A) its not safe to assume
that everyone has that CID (for several reasons), B) the &quot;message
store&quot; of RFC 2392 is not logically equivalent to the CS and C) the
data the CID referneces still has to find some way to get to the CS and
Ive yet to hear how you thinks that will happen.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
--=_alternative 0076662B85256C30_=--


From owner-ietf-calendar@mail.imc.org  Tue Sep 10 18:06:19 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27793
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 18:06:18 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8AM0q226129
	for ietf-calendar-bks; Tue, 10 Sep 2002 15:00:52 -0700 (PDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AM0pk26122
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 15:00:51 -0700 (PDT)
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AM0m703325
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 15:00:48 -0700 (PDT)
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8AM0mp03309
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 15:00:48 -0700 (PDT)
Received: from c1271 (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g8AM0lr12705
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 16:00:47 -0600 (MDT)
Message-ID: <02ae01c25915$fd1c22a0$092e0165@in.steltor.com>
From: "Graham Gilmore" <graham.gilmore@oracle.com>
To: <ietf-calendar@imc.org>
References: <024e01c25903$805f0500$092e0165@in.steltor.com> <3D7E590B.C7A10CC4@Royer.com>
Subject: Re: MIME encapsulation of multipart responses
Date: Tue, 10 Sep 2002 18:04:08 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Doug Royer wrote:
> Graham Gilmore wrote:
> > Nowhere does it say that an CS must extract the contents referenced (for
> > example) by a cid: URI in an ATTACH property or a property with an
ALTREP
> > parameter and store it along with the iCalendar data.
>
> Again - some iMIP implementations can only process text/calendar
> as the only  body part. That does not mean that we must restrict
> CAP to those implementations.

    (a) CAP derives from iTIP, not iMIP.

    (b) While we have precedent for having different levels of capability
with CAP-QL, the assumption is that full support is a superset of CAP-MIN
(or whatever it's called), whereas it's not clear here in this discussion
that a CS or CUA that supports generating multipart MIME messages ("full"
support) must also support not doing so ("minimum" support) as determined by
the capabilities reported by the other party (in fact, someone mentioned an
example where a CS/CUA reports, in essence, "I support *only* multipart
MIME").

> > As an illustration, RFC 2447 gives an interesting example:
> > ...
> > Does this mean that to be a iCalendar-conformant CS, the CS
> > must also know how to retrieve files via FTP and store them?
>
> No. Not unless it is in the same MIME object (and FTP is not).
>
> >  Specifying an ATTACH or ALTREP with a cid: is PERFECTLY VALID
> > iCalendar, I agree 100%.  However, expecting the CS to store &
> > re-deliver to you at a later time anything other than the URI that
> > was in the original iCalendar is ludicrous.  It is the CUA that must
> > resolve the URI.  If you MUST have your ATTACH stored in the CS, put
> > it inline using the VALUE=BINARY parameter and base64 encoding.
>
> What if the URI is a CID to a body part in the same
> MIME object ? - What then do you expect it to retrieve?
> Nothing? Again, not all CSs or CUAs need implement the
> storage for all of the iCalendar object. Some implementations
> can't do recurrence rules - you get an error.

    I would expect that the generator of the message with the CID would make
the referenced message publicly available so that it could be accessed
externally; otherwise, it should not generate such a message (unless both
parties agree that it is acceptable, via capabilities).
    The analogy with iCalendar implementations without RRULEs is flawed.
RRULE is not an optional part of iCalendar, and such an implementation is
incomplete; whereas I seem to see people saying that CAP should have the
multipart thing as a MAY.

> > Otherwise, not only do you have to store the iCalendar, but you have
> > to store all the MIME envelopes for all CAP messages as well just in
> > case someone decides to include a cid: URI to the ATTACH they included
> > with a meeting 6 years ago (oh, did your CS clean up that old data
> > already?  oops!)
>
> If you still have the component and the attachment was sent to
> you inline - what do you expect to do? How will you decide
> to clean those up? It is the same issue. We are NOT mandating
> how the CS stores data. We are NOT mandating any cleanup.

    My point is not that stuff may be cleaned up improperly, but more
broadly that this feature will require a full-featured CAP server to also be
a MIME message repository, by creating new interdependencies between
iCalendar data and the MIME envelope it was transported in (which otherwise
the CS could simply discard).  This complicates the implementation of all
sorts of things, such as cleanup, due to the new dependencies.
    While a CID referring a different part inside the same message is, in
actuality, not a *huge* problem (having the iCalendar parsing code actually
drive the MIME parsing code rather than simply using them as pipeline stages
would allow the extraction of an ATTACH or ALTREP from the MIME envelope;
ugly & doable, although this means that one would no longer be able to take
off-the-shelf MIME and iCalendar libraries and throw them together with a
bit of chewing gum, which is really unfortunate), the scary part is John's
mentions of CIDs (or MIDs) referring to *other* messages, as one can no
longer simply toss the MIME away anymore.
    It also raises the question, just what exactly does iCalendar consist of
then?  Is it purely the textual format specified in RFC 2445, or is does it
more broadly include all other MIME parts referenced by that text that might
be inside the same MIME envelope, but are not necessarily "text/calendar"?
Doug seems to be saying that ignoring the other MIME parts is akin to
ignoring RRULEs inside a VEVENT.  To me, it's quite a different beast.
iCalendar already has a mechanism for including things inline (if you must);
it's called base64 encoding.  Why not simply use that?

    Graham




From owner-ietf-calendar@mail.imc.org  Tue Sep 10 20:14:18 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00071
	for <calsch-archive@lists.ietf.org>; Tue, 10 Sep 2002 20:14:17 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8B05b801284
	for ietf-calendar-bks; Tue, 10 Sep 2002 17:05:37 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8B05Zk01280
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 17:05:35 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8B05abB013866
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Tue, 10 Sep 2002 17:05:38 -0700
Message-ID: <3D7E87D3.9F7C503C@Royer.com>
Date: Tue, 10 Sep 2002 18:01:23 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <024e01c25903$805f0500$092e0165@in.steltor.com> <3D7E590B.C7A10CC4@Royer.com> <02ae01c25915$fd1c22a0$092e0165@in.steltor.com>
Content-Type: multipart/mixed;
 boundary="------------828E4A5362BC074E822F116B"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------828E4A5362BC074E822F116B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Graham Gilmore wrote:
> 
> Doug Royer wrote:
> > Graham Gilmore wrote:
> > > Nowhere does it say that an CS must extract the contents referenced (for
> > > example) by a cid: URI in an ATTACH property or a property with an
> ALTREP
> > > parameter and store it along with the iCalendar data.
> >
> > Again - some iMIP implementations can only process text/calendar
> > as the only  body part. That does not mean that we must restrict
> > CAP to those implementations.
> 
>     (a) CAP derives from iTIP, not iMIP.

CAP and iMIP are both derived from iTIP. iMIP adds no iCalendar
functionality. iMIP is only a transport just as CAP is a
transport (plus storage access).

And from iMIP implementations we can tell that adding attachments
and using ALTREP is used in implementations. I could iMIP you,
and your CUA could not store it? That is the reason I relate iMIP
to CAP.

>     (b) While we have precedent for having different levels of capability
> with CAP-QL, the assumption is that full support is a superset of CAP-MIN
> (or whatever it's called), whereas it's not clear here in this discussion
> that a CS or CUA that supports generating multipart MIME messages ("full"
> support) must also support not doing so ("minimum" support) as determined
> by the capabilities reported by the other party (in fact, someone
> mentioned an example where a CS/CUA reports, in essence, "I support
> *only* multipart MIME").

I did propose the MULTIPART capability reply where each side
in the capability exchange specifies if it can support multipart
or not. I would suspect that if a CS has a multipart object
and the CUA can not handle that, it gets an error instead
of the object. Or would it only get the text/calendar body
part and not be able to resolve the CIDs and MIDs?

> > > As an illustration, RFC 2447 gives an interesting example:
> > > ...
> > > Does this mean that to be a iCalendar-conformant CS, the CS
> > > must also know how to retrieve files via FTP and store them?
> >
> > No. Not unless it is in the same MIME object (and FTP is not).
> >
> > >  Specifying an ATTACH or ALTREP with a cid: is PERFECTLY VALID
> > > iCalendar, I agree 100%.  However, expecting the CS to store &
> > > re-deliver to you at a later time anything other than the URI that
> > > was in the original iCalendar is ludicrous.  It is the CUA that must
> > > resolve the URI.  If you MUST have your ATTACH stored in the CS, put
> > > it inline using the VALUE=BINARY parameter and base64 encoding.
> >
> > What if the URI is a CID to a body part in the same
> > MIME object ? - What then do you expect it to retrieve?
> > Nothing? Again, not all CSs or CUAs need implement the
> > storage for all of the iCalendar object. Some implementations
> > can't do recurrence rules - you get an error.
> 
> I would expect that the generator of the message with the CID would make
> the referenced message publicly available so that it could be accessed
> externally; otherwise, it should not generate such a message (unless both
> parties agree that it is acceptable, via capabilities).

That is not practical. Most users can not export public files
from inside their firewall. That would break ATTACH and ALTREP.

In fact many users do not know how to export a file inside
their firewalls. However ATTACH works for them.

> The analogy with iCalendar implementations without RRULEs is flawed.
> RRULE is not an optional part of iCalendar, and such an implementation is
> incomplete; whereas I seem to see people saying that CAP should have the
> multipart thing as a MAY.

You need to re-read the iTIP restriction tables, RRULE is optional
in an implementation.

And I agree multipart should be a MAY. However if your CUA and CS
supports multipart and you deposit a multipart object, I think we
have to say that a non-multipart CUA can't read it or is unable
to resolve the CIDs and MIDs.

> > > Otherwise, not only do you have to store the iCalendar, but you have
> > > to store all the MIME envelopes for all CAP messages as well just in
> > > case someone decides to include a cid: URI to the ATTACH they included
> > > with a meeting 6 years ago (oh, did your CS clean up that old data
> > > already?  oops!)
> >
> > If you still have the component and the attachment was sent to
> > you inline - what do you expect to do? How will you decide
> > to clean those up? It is the same issue. We are NOT mandating
> > how the CS stores data. We are NOT mandating any cleanup.
> 
> My point is not that stuff may be cleaned up improperly, but more
> broadly that this feature will require a full-featured CAP server
> to also be a MIME message repository, by creating new interdependencies
> between iCalendar data and the MIME envelope it was transported in
> (which otherwise the CS could simply discard).  This complicates the
> implementation of all sorts of things, such as cleanup, due to the
> new dependencies.

I think that we agree on that point.

>While a CID referring a different part inside the same message is, in
> actuality, not a *huge* problem (having the iCalendar parsing code
> actually drive the MIME parsing code rather than simply using them
> as pipeline stages would allow the extraction of an ATTACH or ALTREP
> from the MIME envelope; ugly & doable, although this means that one
> would no longer be able to take off-the-shelf MIME and iCalendar
> libraries and throw them together with a bit of chewing gum, which is
> really unfortunate), the scary part is John's mentions of CIDs (or MIDs)
> referring to *other* messages, as one can no longer simply toss the MIME
> away anymore.

Yes - it complicates things.

There are off the shelf MIME parsers that can handle
CIDs and MIDs. And I have no idea if there is an off the shelf
iCalendar parser that supports CIDs and MIDs.

> It also raises the question, just what exactly does iCalendar consist of
> then?  Is it purely the textual format specified in RFC 2445, or is does
> it more broadly include all other MIME parts referenced by that text
> that might be inside the same MIME envelope, but are not necessarily
> "text/calendar"?

As long as I have been on this mailing list (many years), when
people talk about calendaring, they are also talking about being
able to use alternate representations (you don't have iCal, so I'll
also send you text - multipart/alternate?) and attachments as viewed
by the user in all(?) GUI mailers. 

> Doug seems to be saying that ignoring the other MIME parts is akin to
> ignoring RRULEs inside a VEVENT.  To me, it's quite a different beast.
> iCalendar already has a mechanism for including things inline (if you
> must); it's called base64 encoding.  Why not simply use that?

Because iCalendar also allows for external attachments.
And because iCalendar also allows for external ALTREP.
--------------828E4A5362BC074E822F116B
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------828E4A5362BC074E822F116B--



From owner-ietf-calendar@mail.imc.org  Wed Sep 11 03:46:26 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00775
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 03:46:25 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8B7XwP05016
	for ietf-calendar-bks; Wed, 11 Sep 2002 00:33:58 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8B7Xkk04980
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 00:33:47 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id B393D1552D; Wed, 11 Sep 2002 09:33:45 +0200 (CEST)
Date: Wed, 11 Sep 2002 09:33:45 +0200
From: Andrea Campi <a.campi@inet.it>
To: Bruce_Kahn@notesdev.ibm.com
Cc: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
Message-ID: <20020911073345.GA91461@inet.it>
References: <20020910152152.GE83146@inet.it> <OF52C92333.846AC5CB-ON85256C30.00606DA8-85256C30.0062EE3E@iris.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OF52C92333.846AC5CB-ON85256C30.00606DA8-85256C30.0062EE3E@iris.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Tue, Sep 10, 2002 at 02:00:31PM -0400, Bruce_Kahn@notesdev.ibm.com wrote:
> > What if we mandated that the reply to a SEARCH command (just to
> > pick the most complex example) is contained in one or more VCALENDAR
> > objects in the MIME root, and additional MIME parts can be sent
> > for referenced ATTACHments? 
> 
> If the VCALENDAR (ie: text/calendar) entity _is_ the "MIME root" then you 
> cannot have multiple MIME body parts in the same stream.  If the VCALENDAR 
> entity _is_in_ the MIME root then sounds how iMIP requests are currently 
> formulated (in the simplest format).  That is:
> 
> multipart/related
>         text/calendar
>         application/octet-stream
> 
> or possibly:
> 
> multipart/related
>         multipart/alternative
>                 text/plain
>                 text/calendar
>         application/octet-stream

Uhm, I feel some context is being lost here.

I didn't object to the formats you show, I was objecting about the
possibility of getting:

multipart/related
         text/calendar
		BEGIN:VCALENDAR
		TARGET:aaa
		END:VCALENDAR
         text/calendar
		BEGIN:VCALENDAR
		TARGET:bbb
		END:VCALENDAR
         text/calendar
		BEGIN:VCALENDAR
		TARGET:ccc
		END:VCALENDAR
         text/calendar
		BEGIN:VCALENDAR
		TARGET:ddd
		END:VCALENDAR

as answer to a SEARCH with four targets. This is what I judge
unneeded, unnecessarily complicated and ambiguous. Compare this
with:

multipart/related
         text/calendar
		BEGIN:VCALENDAR
		TARGET:aaa
		END:VCALENDAR
		BEGIN:VCALENDAR
		TARGET:bbb
		END:VCALENDAR
		BEGIN:VCALENDAR
		TARGET:ccc
		END:VCALENDAR
		BEGIN:VCALENDAR
		TARGET:ddd
		END:VCALENDAR

Admittedly, I wasn't clear in my initial posts because I wasn't
thinking about ALTREPs and all, but still I can't see why you can't
add additional parts as easily in the second form as in the first
form.


Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep 11 04:32:54 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01382
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 04:32:54 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8B8OJc13949
	for ietf-calendar-bks; Wed, 11 Sep 2002 01:24:19 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8B8OIk13940
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 01:24:18 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 22F501552D; Wed, 11 Sep 2002 10:24:18 +0200 (CEST)
Date: Wed, 11 Sep 2002 10:24:18 +0200
From: Andrea Campi <a.campi@inet.it>
To: George Babics <george.babics@oracle.com>
Cc: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
Message-ID: <20020911082418.GB91461@inet.it>
References: <3D7E1122.70716473@oracle.com> <3D7E2DB2.284A9556@Royer.com> <3D7E3B30.2D2B9B7C@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D7E3B30.2D2B9B7C@oracle.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Tue, Sep 10, 2002 at 02:34:24PM -0400, George Babics wrote:
>       In other words, how can a small device avoid downloading
>       attachments? It can formulate a query that specifies only
>       the properties that it wants? Is this sufficient?

As you said below in your message, in this environment you would
make sure your only use URIs to reference to attachments. IMHO the
best way to do this would be to use a server that stores any
attachment (whether inline, or referenced to using cid: etc) and
substitute the proper URI. I know because I'm taking that approach.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep 11 07:40:42 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04599
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 07:40:41 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BBWnI00934
	for ietf-calendar-bks; Wed, 11 Sep 2002 04:32:49 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BBWmk00925
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 04:32:48 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 227751552D; Wed, 11 Sep 2002 13:32:44 +0200 (CEST)
Date: Wed, 11 Sep 2002 13:32:44 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Proposal about multipart etc
Message-ID: <20020911113243.GD91461@inet.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


Hi all,

I'm writing this as a proposal to help focus the discussion and above
all make sure I make my point clear. I think at least a few people
agree on my point of view, so I hope nobody finds this out of place.
I'm not asking to include this text in the draft unless people agree
on all of it. And please excuse my english but I'm not a native
speaker.



 1 Multipart in CAP	[note: addition/revision to 3.3.1 in current draft]

The BEEP data exchanged in CAP may take different forms depending on
the data being exchanged and the capabilities of the CUA and the CS.

If data can be sent in different forms, it is advisable to send it
as text/calendar. In particular, most commands can be sent as
test/calendar.


 1.1 text/calendar

If the payload of a BEEP packet is of type text/calendar, it MUST
conform to [iCAL] iCalendar format. This is the only format which
all CAP implementations MUST accept.

 1.2 multipart/related

If the exchanged packets contain multipart/related payload, they MUST
contain at least one text/calendar parts. If it contains more than
one, they are processed in the same order as they appear [note: I
have no strong opinion on this point]. Data in text/calendar parts
MUST conform to [iCAL] iCalendar format.
If a CUA or a CS don't support this form, they MUST respond with an
appropriate REQUEST-STATUS.

[note: obviously, text/calendar MAY be inside text/alternative, and
parts with unknown MIME types can be thrown away. I don't think we
need to state this here]

If needed, additional data can be transmitted in addidional body
parts using the appropriate MIME type; in particular, this can be
used for attachments. Additional body parts are referred to using
CID: etc.

 2 Multipart negotiation

A CUA and a CS SHOULD negotiate the level of multipart support.
This can be done using the GET-CAPABILITY command [note: we must
add a property for this].
A party should assume the other party can't do multipart, and send
a GET-CAPABILITY command as text/calendar. If the answer states that
the other party supports multipart, it can send subsequent commands
using the appropriate form.
As an alternative, a party may opt to start using multipart and switch
to the simpler text/calendar form if it receives an error.

 3 Considerations

 3.1 Graceful degradation

If both parties support multipart, each party may opt to use the
encoding it prefers. However, text/calendar support is mandatory,
which in particular means a CS MUST use text/calendar in replies
to commands if the party only supports that form, with no loss of
data except as indicated in 3.2.
In particular, if the CUA only supports text/calendar:

 - all replies to commands with multiple targets or multiple queries, as
well as replies containing separate components with different METHODs,
must be sent with different iCalendar objects in the same text/calendar

[note: add more here if we want to. I know this is already present
in iCal]

 3.2 Limitations

 3.2.1 cid: URI

A CUA or a CS which doesn't support multipart can't properly handle
properties with a cid: URI value; this affects ATTACH properties and
any property which allows the ALTREP parameter.

A limited CUA SHOULD inform the user that there is an attachment but
it is not able to access it. It should also provide alternative ways
to attach files to outgoing components. One method would be to store
the file on an appropriate file store and store the URI.

A limited CS SHOULD try not to lose ATTACHments. One method would be
to provide an iMIP+CAP client that stores attachments on any appropriate
file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
ATTACH properties to reference the appropriate URI. It is advisable
that CS which have no limitations, but want to support clients with
limited capabilities, do the same conversion, either at time or
retrieval time.




A final note: I purposefully don't address the problem of a limited
CUA or CS not being able to properly process an iMIP message. As some
people noted on the list, a CUA does not HAVE to know about iMIP, nor
does a CS; in fact, a CUA doesn't have to deal with email at all.

If the implementator wants iMIP support it can still use the same
approach as in 3.2.1, that is provide an iMIP+CAP client to do the
processing. This would probably take the form of a filter inside a
MTA or MUA application.


I think this proposal addresses all concerns presented on the list
by advocates of both approaches. An implementor is free to choose
to support limited or complete functionality without limiting the
user. At the same time, this doesn't in any way (that I know of)
violate or restrict any existent RFC.

I expect that complete applications like Outlook or Ximian Evolution
would support the whole enchilada (they have to, anyway), while light
clients (cell phones, CGI interfaces etc) can be much simpler.


Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep 11 07:49:34 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04814
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 07:49:34 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8BBUVv00313
	for ietf-calendar-bks; Wed, 11 Sep 2002 04:30:31 -0700 (PDT)
Received: from eeyore.jsoft.com (24-240-234-245.charter.com [24.240.234.245])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BBUTk00305
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 04:30:29 -0700 (PDT)
Received: from jsoft.com (IDENT:gYca6XHYesJsC+yBHpB/VpxGkSgmRnIR@eeyore.jsoft.com [192.168.0.46])
	by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g8BBOVo07067
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:24:32 -0500
Message-ID: <3D7F27EF.5050808@jsoft.com>
Date: Wed, 11 Sep 2002 06:24:31 -0500
From: Gary Frederick <gary.frederick@jsoft.com>
Organization: Jefferson Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <024e01c25903$805f0500$092e0165@in.steltor.com> <3D7E590B.C7A10CC4@Royer.com> <02ae01c25915$fd1c22a0$092e0165@in.steltor.com> <3D7E87D3.9F7C503C@Royer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug said 'CAP is a transport (plus storage access).'  Yes - a short statement.

I consider that statement key to any conversation we are having. If CAP does not support full featured CS and minimal CS implementations, it's uhhh... less useful.

I want to be able to use CAP to connect servers and clients. What I want to communicate is calendar info. If part of the info requires multipart whatever and CAP doesn't support the communication, 'In My Opinion' CAP is not doing a good job.

If a full featured CAP CS can not transport multipart calendar info and can not access it from it's store, is it providing what we want CAP to provide?

Gary

Doug Royer wrote:
> Graham Gilmore wrote:
> 
>>Doug Royer wrote:
>>
>>>Graham Gilmore wrote:
>>>
>>>>Nowhere does it say that an CS must extract the contents referenced (for
>>>>example) by a cid: URI in an ATTACH property or a property with an
>>>
>>ALTREP
>>
>>>>parameter and store it along with the iCalendar data.
>>>
>>>Again - some iMIP implementations can only process text/calendar
>>>as the only  body part. That does not mean that we must restrict
>>>CAP to those implementations.
>>
>>    (a) CAP derives from iTIP, not iMIP.
> 
> 
> CAP and iMIP are both derived from iTIP. iMIP adds no iCalendar
> functionality. iMIP is only a transport just as CAP is a
> transport (plus storage access).
> 
> And from iMIP implementations we can tell that adding attachments
> and using ALTREP is used in implementations. I could iMIP you,
> and your CUA could not store it? That is the reason I relate iMIP
> to CAP.
> 
> 
>>    (b) While we have precedent for having different levels of capability
>>with CAP-QL, the assumption is that full support is a superset of CAP-MIN
>>(or whatever it's called), whereas it's not clear here in this discussion
>>that a CS or CUA that supports generating multipart MIME messages ("full"
>>support) must also support not doing so ("minimum" support) as determined
>>by the capabilities reported by the other party (in fact, someone
>>mentioned an example where a CS/CUA reports, in essence, "I support
>>*only* multipart MIME").
trim



From owner-ietf-calendar@mail.imc.org  Wed Sep 11 09:16:44 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08248
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:16:43 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BD8Oj07723
	for ietf-calendar-bks; Wed, 11 Sep 2002 06:08:24 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8BD8Nk07719
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:08:23 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091109170520926
 for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:17:05 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 11 Sep 2002 09:06:41 -0400
Message-ID: <3D7F3FE1.2000508@centivinc.com>
Date: Wed, 11 Sep 2002 09:06:41 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <3D7E10FE.B6D4C76D@oracle.com> <3D7E1E7F.BC74DD2B@Royer.com> <3D7E3159.17591799@oracle.com> <3D7E48A5.4088B04D@Royer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Sep 2002 13:06:41.0654 (UTC) FILETIME=[12481160:01C25994]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>The problems with iMIP interoperability is that some decided
>not to fully support CIDs and MIDs and others did.
>
>2445 Does not specify, so both are valid. So I think
>in CAP we have to accomidate both.
>
2445 does not specify, so both are invalid.

>Break iCalendar implementations that already exist and
>that already use multipart.
>
Those are not iCalendar implementations.  They are MUAs with integrated 
iCalendar functionality.  In effect, they took iCalendar and created 
their own extensions by integrating MIME features that are not required 
by 2445; that's a reasonable thing to do, but anyone who does it has to 
accept that it limits their interoperability.

>>No such implication was made. It simply stated that without multipart
>>the only way to send attachments would be to send them inline.
>>    
>>
>
>There is no such restriction in 2445, so it would be a redefined.
>
No, it would be a profile of 2445.

-- 
/===========================================\
|John Stracke      |jstracke@centivinc.com  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/




From owner-ietf-calendar@mail.imc.org  Wed Sep 11 09:18:00 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08324
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:17:59 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BD9Mn07749
	for ietf-calendar-bks; Wed, 11 Sep 2002 06:09:22 -0700 (PDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BD9Lk07745
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:09:21 -0700 (PDT)
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8BD9H712158
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:09:17 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8BD9Gp12145
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:09:16 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8BD9FO27491
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 07:09:16 -0600 (MDT)
Message-ID: <3D7F407A.55C6AAEB@oracle.com>
Date: Wed, 11 Sep 2002 09:09:14 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <3D7E1122.70716473@oracle.com> <3D7E2DB2.284A9556@Royer.com> <3D7E3B30.2D2B9B7C@oracle.com> <3D7E52A6.2456F82C@Royer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Doug Royer wrote:
> 
> George Babics wrote:
> 
> > > >
> > > > A few questions about how to handle attachments:
> > > >
> > > >   1) How can a CUA get all properties of a component except an
> > > >      attachment, which may be very big?
> >
> >       In other words, how can a small device avoid downloading
> >       attachments? It can formulate a query that specifies only
> >       the properties that it wants? Is this sufficient?
> 
> I seem to recall that we had this debate before, and concluded
> that it was sufficient.
> 
> > >
> > > >   2) How do we delete or modify an attachment if a component
> > > >      has multiple attachments? CAP draft specifies that the
> > > >      CUA can specify a part of the attachment such that it
> > > >      is uniquely identified. That means that the CUA must download
> > > >      the entire attachment, upload part of it in the MODIFY command,
> > > >      and upload the entire new attachment. How will the CUA know
> > > >      up to now many bytes of the old attachment uniquely identifies
> > > >      it.
> > >
> > > The ultimate purpose of an attachment is for the CU/CUA. So
> > > there is no way for a CU to know they wanted it modified, unless
> > > they have already have it downloaded or do the download. Ether
> > > way - it is going to have to be downloaded.
> >
> >   What if the CUA simply wants to remove all the attachments?
> > Yes, it has to be downloaded (or maybe not, see #4 below).
> > However, to change it, it will have to download it, then upload it,
> > and upload another attachment. This can be expensive for inline
> > attachments.
> 
> The delete and modification phase only has to download whatever
> makes it unique, not the entire attachment. I would think
> that that is going to be relativity small.
> 
> If you are modifying it, yes you will have to send down
> what you want the new value to become.
> 
> If it is external to the CS (an FTP attachment for example),
> then the modification is going to fail.
> 
> >   However, one may argue that inline attachment will be rare,
> > and people will usually use a URI.
> 
> I don't think we can make that assumption. Some on this
> list seem to be debating for inline only.
> 
> Ether case, it does not matter to the protocol. In both
> cases if they are part of the calendar object, then they
> will both be in the CS no matter how they were transferred.
> 
> > > >   4) How can a CUA let a user know that an event has an attachment
> > > >      without downloading it? This can allow the attachment to be
> > > >      downloaded only if the users "clicks" on it.
> > >
> > > So download it? Again - how the the CU know that is what
> > > they wanted to do without first knowing what it is?
> >
> >   The CUA may want to be able to display to the user that
> > an event has an attachment without downloading it. If the CUA
> > displays a weekly view, it need not download all the attachments
> > for all the events in the view. What it may want to do, is to
> > display an icon in the event, to tell the user that the event has an
> > attachment. The attachment would only be downloaded if the user
> > opens the event, and then decides that he wants to see the attachment.
> >
> >   In general, how can we avoid unnecessarily downloading an inline
> > attachment?
> 
> For an inline attachment (from 2445):
> 
>      ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
>       MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
>       EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
>         <...remainder of "BASE64" encoded binary data...>
> 
>    The VALUE will be BINARY and it will have a known ENCODING.
> 
> For an FTP attachment (from 2445):
> 
>      ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud
> 
>    The VALUE TYPE is URI (the default) and the ATTACH value
>    will start with 'ftp:'. Similar to an HTTP attachment.
> 
> For a CID attachment (from 2445):
> 
>      ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com
> 
>    The VALUE TYPE is URI (the default) and the ATTACH value
>    will start with 'CID:'.
> 
> So I guess you could query for the VALUE from ATTACH and
> look at the results. If the VALUE is BINARY, then it is inline
> to the iCalendar object, else it is in another body part, or
> external to the CS.

How can you do a query so that what is returned to you is
the property's parameter (i.e., "VALUE") and not its value
(the actual inline attachment)?

George


From owner-ietf-calendar@mail.imc.org  Wed Sep 11 09:19:58 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08409
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:19:57 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8BDCWx07910
	for ietf-calendar-bks; Wed, 11 Sep 2002 06:12:32 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8BDCUk07902
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:12:30 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091109211103243
 for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:21:11 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 11 Sep 2002 09:10:48 -0400
Message-ID: <3D7F40D8.2000901@centivinc.com>
Date: Wed, 11 Sep 2002 09:10:48 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF3E633E46.74E254CA-ON85256C30.00656DA7-85256C30.006CD01A@iris.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Sep 2002 13:10:48.0396 (UTC) FILETIME=[A559E8C0:01C25994]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Bruce_Kahn@notesdev.ibm.com wrote:

> BTW: If the ATTACHments were just stored as URIs then it could be 
> hard/impossible for someone on a different system to view the 
> ATTACHment thats saved on my desktop.

Strawman.  People already cope with this problem when writing HTML files.

> ALTREP by definition implys multipart (and so does ATTACH).

False.  From 2445, section 4.2:

     DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
       Conference - - Las Vegas, NV, USA

And section 4.2.8:

      ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/
       agenda.doc

So, clearly, both ALTREP and ATTACH are useful without multipart.

-- 
/===========================================\
|John Stracke      |jstracke@centivinc.com  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/




From owner-ietf-calendar@mail.imc.org  Wed Sep 11 09:20:09 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08426
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:20:09 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BDG8o08099
	for ietf-calendar-bks; Wed, 11 Sep 2002 06:16:08 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8BDG6k08095
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:16:07 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091109244801528
 for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:24:48 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 11 Sep 2002 09:14:24 -0400
Message-ID: <3D7F41B0.7090302@centivinc.com>
Date: Wed, 11 Sep 2002 09:14:24 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <024e01c25903$805f0500$092e0165@in.steltor.com> <3D7E590B.C7A10CC4@Royer.com> <02ae01c25915$fd1c22a0$092e0165@in.steltor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Sep 2002 13:14:24.0856 (UTC) FILETIME=[265F1580:01C25995]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Graham Gilmore wrote:

>    I would expect that the generator of the message with the CID would make
>the referenced message publicly available so that it could be accessed
>externally; otherwise, it should not generate such a message (unless both
>parties agree that it is acceptable, via capabilities).
>
No, that's not necessary.  If I send you a multipart MIME message 
containing an iMIP text/calendar that uses a cid: to point to a 
different part of that message, then your MUA has the entire message 
that's being referenced, and can store it, and dereference the cid: for 
your CUA on demand.  It is not necessary for the body part to be stored 
in the CS.

This type of MUA/CUA integration is out of scope for CAP proper, though 
it might be considered to be implied when one builds an iMIP endpoint 
that uses CAP to store its calendar.

-- 
/===========================================\
|John Stracke      |jstracke@centivinc.com  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/




From owner-ietf-calendar@mail.imc.org  Wed Sep 11 09:20:47 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08451
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:20:46 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8BDBPQ07851
	for ietf-calendar-bks; Wed, 11 Sep 2002 06:11:25 -0700 (PDT)
Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BDBOk07846
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:11:24 -0700 (PDT)
Received: from inet-mail2.oracle.com (localhost [127.0.0.1])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8BDBJZ24720
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:11:19 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8BDBIZ24705
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:11:18 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8BDBEO29370
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 07:11:17 -0600 (MDT)
Message-ID: <3D7F40F0.2F985CB4@oracle.com>
Date: Wed, 11 Sep 2002 09:11:12 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <3D7E1122.70716473@oracle.com> <3D7E2DB2.284A9556@Royer.com> <3D7E3B30.2D2B9B7C@oracle.com> <20020911082418.GB91461@inet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Yes, this is the approach I was thinking of taking.

George

Andrea Campi wrote:
> 
> On Tue, Sep 10, 2002 at 02:34:24PM -0400, George Babics wrote:
> >       In other words, how can a small device avoid downloading
> >       attachments? It can formulate a query that specifies only
> >       the properties that it wants? Is this sufficient?
> 
> As you said below in your message, in this environment you would
> make sure your only use URIs to reference to attachments. IMHO the
> best way to do this would be to use a server that stores any
> attachment (whether inline, or referenced to using cid: etc) and
> substitute the proper URI. I know because I'm taking that approach.
> 
> Bye,
>         Andrea
> 
> --
> Andrea Campi                              mailto:a.campi@inet.it
> I.NET S.p.A.                              http://www.inet.it
> Direzione Tecnica - R&D                   phone: +39 02 32863 ext 1
> v. Darwin, 85 - I-20019                   fax: +39 02 32863 ext 7705
> Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep 11 09:21:11 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08479
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:21:11 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BD5fp07637
	for ietf-calendar-bks; Wed, 11 Sep 2002 06:05:41 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8BD5dk07633
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:05:39 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091109142103461
 for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:14:21 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 11 Sep 2002 09:03:57 -0400
Message-ID: <3D7F3F3D.2050609@centivinc.com>
Date: Wed, 11 Sep 2002 09:03:57 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris.com> <3D7E1D14.9070304@centivinc.com> <3D7E2D1B.5FECCBC@Royer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Sep 2002 13:03:57.0304 (UTC) FILETIME=[B0523F80:01C25993]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>John Stracke wrote:
>  
>
>>Because a sensible CAP server will be backed by a relational database,
>>and should not be required to store blobs.
>>    
>>
>I do not see the correlation. If the iCalendar object contains
>an inline attachment - are your going to throw it away?
>
Uh.  This is a good point.  However, I think it's not conclusive, since 
the inline attachments are typically much smaller than the type of 
attachments that people send around in email.  A CS could usefully 
implement inline attachments, with a length limit, for a much lower cost 
than arbitrary MIME attachments.

-- 
/===========================================\
|John Stracke      |jstracke@centivinc.com  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/




From owner-ietf-calendar@mail.imc.org  Wed Sep 11 09:24:44 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08723
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:24:43 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8BDIYC08158
	for ietf-calendar-bks; Wed, 11 Sep 2002 06:18:34 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8BDIWk08153
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:18:32 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091109271415580
 for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:27:14 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 11 Sep 2002 09:16:51 -0400
Message-ID: <3D7F4242.3040505@centivinc.com>
Date: Wed, 11 Sep 2002 09:16:50 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <024e01c25903$805f0500$092e0165@in.steltor.com> <3D7E590B.C7A10CC4@Royer.com> <02ae01c25915$fd1c22a0$092e0165@in.steltor.com> <3D7E87D3.9F7C503C@Royer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Sep 2002 13:16:51.0079 (UTC) FILETIME=[7D86F170:01C25995]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>As long as I have been on this mailing list (many years), when
>people talk about calendaring, they are also talking about being
>able to use alternate representations (you don't have iCal, so I'll
>also send you text - multipart/alternate?)
>
But, by definition, things that are done to support people who don't 
have iCalendar are out of scope for iCalendar.

You're talking about how people with MIME MUAs communicate; that's 
useful for MUA implementers to know, but it's not part of iCalendar.  It 
is entirely clear from 2445 that iCalendar is not tied to MIME.

-- 
/===========================================\
|John Stracke      |jstracke@centivinc.com  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/




From owner-ietf-calendar@mail.imc.org  Wed Sep 11 10:11:51 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08247
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:16:43 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8BD90A07736
	for ietf-calendar-bks; Wed, 11 Sep 2002 06:09:00 -0700 (PDT)
Received: from CarWash.IncentiveSystems.com ([65.220.90.249])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8BD8wk07732
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 06:08:59 -0700 (PDT)
Received: from minglewood.incentivesystems.com ([172.16.0.25])
 by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002091109174013513
 for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:17:40 -0400
Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 11 Sep 2002 09:07:16 -0400
Message-ID: <3D7F4004.6010407@centivinc.com>
Date: Wed, 11 Sep 2002 09:07:16 -0400
From: John Stracke <jstracke@centivinc.com>
Organization: Centiv
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: MIME encapsulation of multipart responses
References: <OF9542A089.8F4EF975-ON85256C30.00505DF6-85256C30.00523A47@iris> <3D7E1A38.8090204@samsungcontact.com> <3D7E2346.1FFAE22C@Royer.com> <3D7E3391.3050703@centivinc.com> <3D7E4965.D8F4D5CD@Royer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Sep 2002 13:07:16.0858 (UTC) FILETIME=[2743C5A0:01C25994]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug Royer wrote:

>John Stracke wrote:
>  
>
>>Strawman alert: the question was about external attachments, not inline
>>ones.
>>    
>>
>
>No, it was about attachments inside the MIME multipart vs
>inline in the same text/calendar.
>
That is what I meant--external to the text/calendar.

-- 
/===========================================\
|John Stracke      |jstracke@centivinc.com  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/




From owner-ietf-calendar@mail.imc.org  Wed Sep 11 12:37:22 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15593
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 12:37:22 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BGNFO19829
	for ietf-calendar-bks; Wed, 11 Sep 2002 09:23:15 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BGNEk19823
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:23:14 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8BGN2bB020691
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:23:05 -0700
Message-ID: <3D7F6CE1.D5D5AEC4@Royer.com>
Date: Wed, 11 Sep 2002 10:18:41 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <3D7E1122.70716473@oracle.com> <3D7E2DB2.284A9556@Royer.com> <3D7E3B30.2D2B9B7C@oracle.com> <3D7E52A6.2456F82C@Royer.com> <3D7F407A.55C6AAEB@oracle.com>
Content-Type: multipart/mixed;
 boundary="------------B7C3A5E5CACFAD54061ECF95"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------B7C3A5E5CACFAD54061ECF95
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

George Babics wrote:

> > So I guess you could query for the VALUE from ATTACH and
> > look at the results. If the VALUE is BINARY, then it is inline
> > to the iCalendar object, else it is in another body part, or
> > external to the CS.
> 
> How can you do a query so that what is returned to you is
> the property's parameter (i.e., "VALUE") and not its value
> (the actual inline attachment)?



Given:

	 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:...

   'VALUE' is a parameter - not 'the value of the property':

Do a:
	   SELECT UID,PARAM(ATTACH, VALUE) FROM EVENT

Would return URI or BINARY for ATTACH. This limited example
would give you a list of the ATTACH VALUE types for all VEVENTs.

-->NOTE: The current ABNF is busted - we somehow dropped parameters
from being selectable.
--------------B7C3A5E5CACFAD54061ECF95
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------B7C3A5E5CACFAD54061ECF95--



From owner-ietf-calendar@mail.imc.org  Wed Sep 11 12:51:13 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16138
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 12:51:13 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BGfiq20852
	for ietf-calendar-bks; Wed, 11 Sep 2002 09:41:44 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BGfYk20843
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:41:36 -0700 (PDT)
In-Reply-To: <3D7E40EB.A227C71B@oracle.com>
To: George Babics <george.babics@oracle.com>
Cc: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OFA259AF3F.DEB533B7-ON85256C31.005AC8A5-85256C31.005B7FC1@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Wed, 11 Sep 2002 12:39:35 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/11/2002 12:36:12 PM,
	Serialize complete at 09/11/2002 12:36:14 PM,
	Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/11/2002 12:36:14 PM
Content-Type: multipart/alternative; boundary="=_alternative 005B7FBA85256C31_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 005B7FBA85256C31_=
Content-Type: text/plain; charset="US-ASCII"

George Babics replied on 09/10/2002 02:58:51 PM:
>   Attachments need not have a CID. When they are returned in MIME to the 
CUA
>   they can have a CID. They also can be inline.

Correct if you are referring to RFC 2445 that defines the ATTACH property 
as having a URI value.  In the multipart MIME case though its more than 
likely going to be a CID or inlined.  I would hope that noone is using 
inlined binaries for big ATTACHments but thats their choice if they do.

One factor that keeps twisting discussions I think is the line between 
whats possible and whats likely or intended.  If we as implementors do not 
plan to code our engines to create content in all the possible ways (but 
can support them) and focus on whats likely or intended then things could 
speed up and we could get some concensus.

If you or anyone want to inline a 5M ZIP archive then go ahead.  I know my 
engine can detect and deal with it (and save the data for the workflow 
engine above the parse thats doing the heavy lifting).  I think that 
inlining should go away since we rarely have 'small' binaries to attach as 
some suggested originally.  The same kind of intent vs possiblity filter 
needs to be applied to the MID/CID talks too but thats just my humble 
opinion.

What about the rest of what I said or asked...??

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...


--=_alternative 005B7FBA85256C31_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>George Babics replied on 09/10/2002 02:58:51 PM:<br>
&gt; &nbsp; Attachments need not have a CID. When they are returned in
MIME to the CUA<br>
&gt; &nbsp; they can have a CID. They also can be inline.<br>
</tt></font>
<br><font size=2 face="sans-serif">Correct if you are referring to RFC
2445 that defines the ATTACH property as having a URI value. &nbsp;In the
multipart MIME case though its more than likely going to be a CID or inlined.
&nbsp;I would hope that noone is using inlined binaries for big ATTACHments
but thats their choice if they do.</font>
<br>
<br><font size=2 face="sans-serif">One factor that keeps twisting discussions
I think is the line between whats possible and whats likely or intended.
&nbsp;If we as implementors do not plan to code our engines to create content
in all the possible ways (but can support them) and focus on whats likely
or intended then things could speed up and we could get some concensus.</font>
<br>
<br><font size=2 face="sans-serif">If you or anyone want to inline a 5M
ZIP archive then go ahead. &nbsp;I know my engine can detect and deal with
it (and save the data for the workflow engine above the parse thats doing
the heavy lifting). &nbsp;I think that inlining should go away since we
rarely have 'small' binaries to attach as some suggested originally. &nbsp;The
same kind of intent vs possiblity filter needs to be applied to the MID/CID
talks too but thats just my humble opinion.</font>
<br>
<br><font size=2 face="sans-serif">What about the rest of what I said or
asked...??</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
<br>
--=_alternative 005B7FBA85256C31_=--


From owner-ietf-calendar@mail.imc.org  Wed Sep 11 13:26:53 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15592
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 12:37:22 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BGQmF20032
	for ietf-calendar-bks; Wed, 11 Sep 2002 09:26:48 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BGQlk20027
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:26:47 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8BGQkbB020722
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 09:26:48 -0700
Message-ID: <3D7F6DC1.9327C96F@Royer.com>
Date: Wed, 11 Sep 2002 10:22:25 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: MIME encapsulation of multipart responses
References: <024e01c25903$805f0500$092e0165@in.steltor.com> <3D7E590B.C7A10CC4@Royer.com> <02ae01c25915$fd1c22a0$092e0165@in.steltor.com> <3D7E87D3.9F7C503C@Royer.com> <3D7F4242.3040505@centivinc.com>
Content-Type: multipart/mixed;
 boundary="------------A9E6CB55D181F443B773FEAD"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------A9E6CB55D181F443B773FEAD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Stracke wrote:
> 
> Doug Royer wrote:
> 
> >As long as I have been on this mailing list (many years), when
> >people talk about calendaring, they are also talking about being
> >able to use alternate representations (you don't have iCal, so I'll
> >also send you text - multipart/alternate?)
> >
> But, by definition, things that are done to support people who don't
> have iCalendar are out of scope for iCalendar.
> 
> You're talking about how people with MIME MUAs communicate; that's
> useful for MUA implementers to know, but it's not part of iCalendar.  It
> is entirely clear from 2445 that iCalendar is not tied to MIME.

No, I am talking about making a CUA as useful as a modern MUA.
--------------A9E6CB55D181F443B773FEAD
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------A9E6CB55D181F443B773FEAD--



From owner-ietf-calendar@mail.imc.org  Wed Sep 11 13:31:26 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17843
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 13:31:25 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BHEje22630
	for ietf-calendar-bks; Wed, 11 Sep 2002 10:14:45 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BHEik22626
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 10:14:44 -0700 (PDT)
In-Reply-To: <3D7E4EF9.347E75E8@Royer.com>
To: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09032002NP September 03, 2002
Message-ID: <OFD5CB798A.DB604AB0-ON85256C31.005BA879-85256C31.005EB60B@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Wed, 11 Sep 2002 13:14:40 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/11/2002 01:09:15 PM,
	Serialize complete at 09/11/2002 01:09:15 PM
Content-Type: multipart/alternative; boundary="=_alternative 005EB60785256C31_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 005EB60785256C31_=
Content-Type: text/plain; charset="US-ASCII"

Doug replied on 09/10/2002 03:58:49 PM:
> The reason for inline attachments was to allow for small
> attachments. The reason for MIME body part attachments
> was to allow for multiple CID/MID links and not force
> replication of the data especially then the attachments are
> huge, and to allow for huge attachments.

There is also the motiviation that its easier to include the referenced 
data than to expect/assume that it will be 'reachable' by the recipient 
thru firewalls, disconnected usage, etc.  (I know of places that wont 
allow outbound HTTP traffic during "business hours" to keep employees 
focused on work instead of surfing so we are not always a big happy 
interconnected world that we dream of...)

Besides, unless the UA that I have saves all body parts after I delete 
them from my store and somehow knows when to purge them, its not 
guaranteed that a CID will still exist in another message stream inside 
the message store.  As such a followup message may try to refer to a CID 
in a message that Ive removed or thats been archived or deleted or 
corrupted or...  The _only_ sure way to be certain that the referenced CID 
exists is if its in the same message stream (even if it comes after the 
referecencing body part).  (BTW: I used "message store" here but it 
equally applies to the calendar or other store too so dont get your 
knickers in a twist!).

> There are CELL phones now that do video. Why not cell
> calendar entries that have huge attachments?

Why not indeed.  Sounds like a UA/bandwidth/footprint issue.  Im sure we 
can find a workable solution as long as we have a clear, common view of 
the problems...

> > Each ATTACHment must have a CID that is unique (unless you wanted to
> > attach multiple copies of the same file!).  As such, you can uniquely
> > identify them based on their CID value (sic).  As for
> > updating/removing them, thats a total haze to me.  I can suggest ways
> > that Ive seen it done for MHTML messages but those kinds of solutions
> > basically involve resaving the entire stream and removing the old
> > copy(s).  No "delta" operations there...
> 
> We allow the CUA to send down all or just what uniquely identifies
> the attachment for removal or modification. It is not relevant
> to the protocol if the attachment in inlined or not, it is just
> required to be in the CS.

Actually you only allow that for inlined binary:

   When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
   identify the contents of the ATTACHMENT value in the old-values in
   order to delete them.

so that does not currently apply to non-inlined ATTACHments.

> > ...Of course this could lead to some nasty/corrupted files if both you
> > and your AA modify the same ZIP archive and dont actually have a way
> > to detect that the 'original' copy has changed to a newer one (when
> > the slower of the two of you try to do the MODIFY).  I strongly doubt
> > you want to build in some kind of locking or checkout mechanism (ala
> > WebDAV) into this or at least I hope not...  So whats the
> > solution??...
> 
> I think this falls into we do not specify transactional
> integrity in CAP. We have explicitly limited CAP in this
> way - per the Dallas meeting which formulated the CAP
> requirements document.

The draft currently does not reference how to actually 'modify' an 
existing inlined ATTACHMENT, merely how to identify one to remove (so why 
is this under 9.5 MODIFY???):

   When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
   identify the contents of the ATTACHMENT value in the old-values in
   order to delete them.  When the CS compares the attachment data it is
   compared in its binary form.  The ATTACHMENT value supplied by the
   CUA MUST BE valid encoded information.

[Emphasis mine]  There is no talk of actually modifying inline 
ATTACHments, just how to remove them.  There is also no clear info on what 
to do to modify or remove non-inlined ATTACHments.  I would expect that to 
remove them simply specifying a CID / URI could be sufficient but to 
modify them is a different story.

> We allow them to specify just what they want to change. And yes,
> if the attachment is a URI, they can just change the URI value.

Here is a bit of hand waving I think. 

If the URI is an 'external' URI ala an HTTP link to an external file then 
this could be fine (you are assuming that the management of the files on 
the server are done via some external mechanism but do not clearly state 
as such). 

However, if the URI is a CID to an entity in the calendar then just what 
happens to this body part if noone references it?  How is the entity 
created/modified/removed from the actual store?  If my UA simply changed 
ATTACH:cid:<12345@foo.net> to ATTACH:cid:<67890@foo.net> then what becomes 
of the data at cid:<12345@foo.net> and how does the new data get to 
cid:<67890@foo.net>?? 

> Also the data. I don't see that is is relevant to the protocol.
> If the attachment is inlined or in a separate body part. In both
> cases you send what is unique to the data.

Its relevant to the spec if its unclear to readers.  The cited text needs 
to be clearer (at least to George and I) or else others may also have the 
same confusion about it...

> If you were to say:
> 
>    SELECT ATTACH from VEVENT where uid='1'
> 
> I could expect a MIME object with 2 body parts, one being
> the REPLY, the other being the attachment. Or one (the REPLY)
> with an inline attachment. Both are valid iCalendar objects.

Works for me.  However, the George was referring to 9.5 (MODIFY Command), 
not SELECT...  In that case the CUA is sending the data to the CS, in your 
case its retrieving it.

> CIDs to non-CAP external attachments are allowed, (IMAP: for example).
> We and 2445 have no such restriction. So the only checking could be
> for MIME object that are inline or packaged in the same MIME object
> could be checked.

What about CAP non-external ATTACHments (ie: a CID to a previously sent 
REQUESTs ATTACHment)?  (This seems to be something John is keen on 
stressing in the multipart discussion...)

I do agree that only safe way to send the ATTACH is to put it into a same 
MIME object/stream (see previous postings for why).

> > >   4) How can a CUA let a user know that an event has an attachment
> > >      without downloading it? This can allow the attachment to be
> > >      downloaded only if the users "clicks" on it.
> > 
> > No clue how.  Id love to see a good way for the CUA to get info about
> > ATTACHments (inlined or not) and have some way to do this...
> 
> Looking for proposals :-)

That sounds like you have an idea but no text (or are crafting text as I 
respond....)  Im mulling over an idea but nothing I want to throw out for 
the wolves just yet.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...


--=_alternative 005EB60785256C31_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug replied on 09/10/2002 03:58:49 PM:<br>
&gt; The reason for inline attachments was to allow for small<br>
&gt; attachments. The reason for MIME body part attachments<br>
&gt; was to allow for multiple CID/MID links and not force<br>
&gt; replication of the data especially then the attachments are<br>
&gt; huge, and to allow for huge attachments.<br>
</tt></font>
<br><font size=2 face="sans-serif">There is also the motiviation that its
easier to include the referenced data than to expect/assume that it will
be 'reachable' by the recipient thru firewalls, disconnected usage, etc.
&nbsp;(I know of places that wont allow outbound HTTP traffic during &quot;business
hours&quot; to keep employees focused on work instead of surfing so we
are not always a big happy interconnected world that we dream of...)</font>
<br>
<br><font size=2 face="sans-serif">Besides, unless the UA that I have saves
all body parts after I delete them from my store and somehow knows when
to purge them, its not guaranteed that a CID will still exist in another
message stream inside the message store. &nbsp;As such a followup message
may try to refer to a CID in a message that Ive removed or thats been archived
or deleted or corrupted or... &nbsp;The _<u>only</u>_ sure way to be certain
that the referenced CID exists is if its in the same message stream (even
if it comes after the referecencing body part). &nbsp;(BTW: I used &quot;message
store&quot; here but it equally applies to the calendar or other store
too so dont get your knickers in a twist!).</font>
<br>
<br><font size=2><tt>&gt; There are CELL phones now that do video. Why
not cell<br>
&gt; calendar entries that have huge attachments?<br>
</tt></font>
<br><font size=2 face="sans-serif">Why not indeed. &nbsp;Sounds like a
UA/bandwidth/footprint issue. &nbsp;Im sure we can find a workable solution
as long as we have a clear, common view of the problems...</font>
<br>
<br><font size=2><tt>&gt; &gt; Each ATTACHment must have a CID that is
unique (unless you wanted to<br>
&gt; &gt; attach multiple copies of the same file!). &nbsp;As such, you
can uniquely<br>
&gt; &gt; identify them based on their CID value (sic). &nbsp;As for<br>
&gt; &gt; updating/removing them, thats a total haze to me. &nbsp;I can
suggest ways<br>
&gt; &gt; that Ive seen it done for MHTML messages but those kinds of solutions<br>
&gt; &gt; basically involve resaving the entire stream and removing the
old<br>
&gt; &gt; copy(s). &nbsp;No &quot;delta&quot; operations there...<br>
&gt; <br>
&gt; We allow the CUA to send down all or just what uniquely identifies<br>
&gt; the attachment for removal or modification. It is not relevant<br>
&gt; to the protocol if the attachment in inlined or not, it is just<br>
&gt; required to be in the CS.<br>
</tt></font>
<br><font size=2 face="sans-serif">Actually you only allow that for inlined
binary:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;When it comes to inline ATTACHMENTs,
the CUA only needs to uniquely<br>
 &nbsp; identify the contents of the ATTACHMENT value in the old-values
in<br>
 &nbsp; order to delete them.</tt></font>
<br>
<br><font size=2 face="sans-serif">so that does not currently apply to
non-inlined ATTACHments.</font>
<br>
<br><font size=2><tt>&gt; &gt; ...Of course this could lead to some nasty/corrupted
files if both you<br>
&gt; &gt; and your AA modify the same ZIP archive and dont actually have
a way<br>
&gt; &gt; to detect that the 'original' copy has changed to a newer one
(when<br>
&gt; &gt; the slower of the two of you try to do the MODIFY). &nbsp;I strongly
doubt<br>
&gt; &gt; you want to build in some kind of locking or checkout mechanism
(ala<br>
&gt; &gt; WebDAV) into this or at least I hope not... &nbsp;So whats the<br>
&gt; &gt; solution??...<br>
&gt; <br>
&gt; I think this falls into we do not specify transactional<br>
&gt; integrity in CAP. We have explicitly limited CAP in this<br>
&gt; way - per the Dallas meeting which formulated the CAP<br>
&gt; requirements document.<br>
</tt></font>
<br><font size=2><tt>The draft currently does not reference how to actually
'modify' an existing inlined ATTACHMENT, merely how to identify one to
remove (so why is this under 9.5 MODIFY???):</tt></font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;When it comes to </tt></font><font size=2 color=blue><tt><b>inline</b></tt></font><font size=2><tt>
ATTACHMENTs, the CUA only needs to uniquely<br>
 &nbsp; identify the contents of the ATTACHMENT value in the old-values
in<br>
 &nbsp; order to </tt></font><font size=2 color=blue><tt><b>delete</b></tt></font><font size=2><tt>
them. &nbsp;When the CS compares the attachment data it is<br>
 &nbsp; compared in its binary form. &nbsp;The ATTACHMENT value supplied
by the<br>
 &nbsp; CUA MUST BE valid encoded information.</tt></font><font size=3><tt><br>
</tt></font>
<br><font size=2 face="sans-serif">[Emphasis mine] &nbsp;There is no talk
of actually modifying inline ATTACHments, just how to remove them. &nbsp;There
is also no clear info on what to do to modify or remove non-inlined ATTACHments.
&nbsp;I would expect that to remove them simply specifying a CID / URI
could be sufficient but to modify them is a different story.</font>
<br>
<br><font size=2><tt>&gt; We allow them to specify just what they want
to change. And yes,<br>
&gt; if the attachment is a URI, they can just change the URI value.<br>
</tt></font>
<br><font size=2 face="sans-serif">Here is a bit of hand waving I think.
&nbsp;</font>
<br>
<br><font size=2 face="sans-serif">If the URI is an 'external' URI ala
an HTTP link to an external file then this could be fine (you are assuming
that the management of the files on the server are done via some external
mechanism but do not clearly state as such). &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">However, if the URI is a CID to an entity
in the calendar then just what happens to this body part if noone references
it? &nbsp;How is the entity created/modified/removed from the actual store?
&nbsp;If my UA simply changed ATTACH:cid:&lt;12345@foo.net&gt; to ATTACH:cid:&lt;67890@foo.net&gt;
then what becomes of the data at cid:&lt;12345@foo.net&gt; and how does
the new data get to cid:&lt;67890@foo.net&gt;?? &nbsp;</font>
<br>
<br><font size=2><tt>&gt; Also the data. I don't see that is is relevant
to the protocol.<br>
&gt; If the attachment is inlined or in a separate body part. In both<br>
&gt; cases you send what is unique to the data.<br>
</tt></font>
<br><font size=2 face="sans-serif">Its relevant to the spec if its unclear
to readers. &nbsp;The cited text needs to be clearer (at least to George
and I) or else others may also have the same confusion about it...</font>
<br>
<br><font size=2><tt>&gt; If you were to say:<br>
&gt; <br>
&gt; &nbsp; &nbsp;SELECT ATTACH from VEVENT where uid='1'<br>
&gt; <br>
&gt; I could expect a MIME object with 2 body parts, one being<br>
&gt; the REPLY, the other being the attachment. Or one (the REPLY)<br>
&gt; with an inline attachment. Both are valid iCalendar objects.<br>
</tt></font>
<br><font size=2 face="sans-serif">Works for me. &nbsp;However, the George
was referring to 9.5 (MODIFY Command), not SELECT... &nbsp;In that case
the CUA is sending the data to the CS, in your case its retrieving it.</font>
<br>
<br><font size=2><tt>&gt; CIDs to non-CAP external attachments are allowed,
(IMAP: for example).<br>
&gt; We and 2445 have no such restriction. So the only checking could be<br>
&gt; for MIME object that are inline or packaged in the same MIME object<br>
&gt; could be checked.<br>
</tt></font>
<br><font size=2 face="sans-serif">What about CAP non-external ATTACHments
(ie: a CID to a previously sent REQUESTs ATTACHment)? &nbsp;(This seems
to be something John is keen on stressing in the multipart discussion...)</font>
<br>
<br><font size=2 face="sans-serif">I do agree that only safe way to send
the ATTACH is to put it into a same MIME object/stream (see previous postings
for why).</font>
<br>
<br><font size=2><tt>&gt; &gt; &gt; &nbsp; 4) How can a CUA let a user
know that an event has an attachment<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;without downloading it? This can allow
the attachment to be<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;downloaded only if the users &quot;clicks&quot;
on it.<br>
&gt; &gt; <br>
&gt; &gt; No clue how. &nbsp;Id love to see a good way for the CUA to get
info about<br>
&gt; &gt; ATTACHments (inlined or not) and have some way to do this...<br>
&gt; <br>
&gt; Looking for proposals :-)</tt></font>
<br>
<br><font size=2 face="sans-serif">That sounds like you have an idea but
no text (or are crafting text as I respond....) &nbsp;Im mulling over an
idea but nothing I want to throw out for the wolves just yet.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
<br>
--=_alternative 005EB60785256C31_=--


From owner-ietf-calendar@mail.imc.org  Wed Sep 11 14:31:10 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20473
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 14:31:09 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BIJ2j27294
	for ietf-calendar-bks; Wed, 11 Sep 2002 11:19:02 -0700 (PDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BIJ1k27286
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 11:19:01 -0700 (PDT)
Received: from inet-mail3.oracle.com (localhost [127.0.0.1])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8BIIwP15429
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 11:18:58 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8BIIvR15422
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 11:18:57 -0700 (PDT)
Received: from c-1241.in.steltor.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8BIIsO20663
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 12:18:55 -0600 (MDT)
Subject: Re: [Fwd: How To Handle Attachments]
From: Patrice Lapierre <patrice.lapierre@oracle.com>
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
In-Reply-To: <3D7F6CE1.D5D5AEC4@Royer.com>
References: <3D7E1122.70716473@oracle.com> <3D7E2DB2.284A9556@Royer.com>
	<3D7E3B30.2D2B9B7C@oracle.com> <3D7E52A6.2456F82C@Royer.com>
	<3D7F407A.55C6AAEB@oracle.com>  <3D7F6CE1.D5D5AEC4@Royer.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 
Date: 11 Sep 2002 14:15:13 -0400
Message-Id: <1031768117.19167.49.camel@c-1241.in.steltor.com>
Mime-Version: 1.0
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


On Wed, 2002-09-11 at 12:18, Doug Royer wrote:
> George Babics wrote:
> > How can you do a query so that what is returned to you is
> > the property's parameter (i.e., "VALUE") and not its value
> > (the actual inline attachment)?
> 
> Given:
> 
> 	 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:...
> 
>    'VALUE' is a parameter - not 'the value of the property':
> 
> Do a:
> 	   SELECT UID,PARAM(ATTACH, VALUE) FROM EVENT
> 
> Would return URI or BINARY for ATTACH. This limited example
> would give you a list of the ATTACH VALUE types for all VEVENTs.
> 
> -->NOTE: The current ABNF is busted - we somehow dropped parameters
> from being selectable.

As far as I know parameters were never individually selectable.

It could be a nice feature for attachments. However we must realize 
that this feature would allow a CAP server to return invalid iCalendar
objects, since the empty value is not accepted by all data types.

For example, consider:

  SELECT PARAM( DTSTART, TZID ) FROM VEVENT

I would expect the CS to return only the TZID parameter
of the DTSTART property but not the value.

e.g., 
   
   VEVENT:BEGIN
   DTSTART;TZID=US-Eastern:
   VEVENT:END

Which is invalid since the empty value is not a valid value for 
the type DATE or DATE-TIME.

That being said, it might not be a huge issue since the CUA has
to explicitly request it.
 
--
Patrice.



From owner-ietf-calendar@mail.imc.org  Wed Sep 11 14:33:53 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20561
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 14:33:53 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BIO7728034
	for ietf-calendar-bks; Wed, 11 Sep 2002 11:24:07 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BIO6k28026
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 11:24:06 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8BIO5bB021547
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 11:24:08 -0700
Message-ID: <3D7F893F.2AA1D4EE@Royer.com>
Date: Wed, 11 Sep 2002 12:19:43 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <OFD5CB798A.DB604AB0-ON85256C31.005BA879-85256C31.005EB60B@iris.com>
Content-Type: multipart/mixed;
 boundary="------------83E5C40EA134C1A9E38E41D8"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------83E5C40EA134C1A9E38E41D8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce_Kahn@notesdev.ibm.com wrote:

> > We allow the CUA to send down all or just what uniquely identifies
> > the attachment for removal or modification. It is not relevant
> > to the protocol if the attachment in inlined or not, it is just
> > required to be in the CS.
> 
> Actually you only allow that for inlined binary:

Yes - your right.

> > When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
> > identify the contents of the ATTACHMENT value in the old-values in
> > order to delete them.
> 
> so that does not currently apply to non-inlined ATTACHments.

Yep - your right.


> The draft currently does not reference how to actually 'modify' an
> existing inlined ATTACHMENT, merely how to identify one to remove (so
> why is this under 9.5 MODIFY???):

It would work for inline attachments:

	WAS:
		ATTACH ......:old---data

	NOW:

		ATTACH ......:new---data
	

> > When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
> > identify the contents of the ATTACHMENT value in the old-values in
> > order to delete them.  When the CS compares the attachment data it
> > is compared in its binary form.  The ATTACHMENT value supplied by the
> >  CUA MUST BE valid encoded information.
> 
> [Emphasis mine]  There is no talk of actually modifying inline
> ATTACHments, just how to remove them.  There is also no clear info on
> what to do to modify or remove non-inlined ATTACHments.  I would
> expect that to remove them simply specifying a CID / URI could be
> sufficient but to modify them is a different story.

It would work for removal and modification of inline attachments.

> > We allow them to specify just what they want to change. And yes,
> > if the attachment is a URI, they can just change the URI value.
> 
> Here is a bit of hand waving I think.
> 
> If the URI is an 'external' URI ala an HTTP link to an external file
> then this could be fine (you are assuming that the management of the
> files on the server are done via some external mechanism but do not
> clearly state as such).

Yes - you could modify the URL, or you can modify the inline attachment
value, but you can not modify the value of a non-inline attachment,
or the value of a CID or MID body part.

> However, if the URI is a CID to an entity in the calendar then just
> what happens to this body part if noone references it?

Why would that be any different than a long DESCRIPTION value?
Would you keep that around?

> How is the entity created/modified/removed from the actual store?

That's up to the implementation. I assumed that you mean
the value that the CID is pointing to? And I assumed you
meant that it had arrived as a body part to the original
message?

> If my UA simply changed ATTACH:cid:<12345@foo.net> to
> ATTACH:cid:<67890@foo.net> then what becomes of the data at
> cid:<12345@foo.net> and how does the new data get to
> cid:<67890@foo.net>??

If you update the component to the new attach value, then
that has nothing to do with the fact that cid:<12345@foo.net>
is still valid or might not be valid.

The only thing you do is inform the CS that the ATTACH value
is now a different CID. If the CID value is stored in the CS
(inlined or body part), then the CS will need to know how to
do its own garbage collection.

> > Also the data. I don't see that is is relevant to the protocol.
> > If the attachment is inlined or in a separate body part. In both
> > cases you send what is unique to the data.
> 
> Its relevant to the spec if its unclear to readers.  The cited text
> needs to be clearer (at least to George and I) or else others may also
> have the same confusion about it...

That's fine. I have noted it in my copy. If anyone has any
proposals for new text - please post. Otherwise in a week or
two after this settles down, I'll add/change text.

> > If you were to say:
> >
> >    SELECT ATTACH from VEVENT where uid='1'
> >
> > I could expect a MIME object with 2 body parts, one being
> > the REPLY, the other being the attachment. Or one (the REPLY)
> > with an inline attachment. Both are valid iCalendar objects.
> 
> Works for me.  However, the George was referring to 9.5 (MODIFY
> Command), not SELECT...  In that case the CUA is sending the data to
> the CS, in your case its retrieving it.

Okay. Any object a CS implementation can send, I would think
it better be able to receive. So my reply may have not
been dead center, but I think it still applied for both
directions of data transfer.

> > CIDs to non-CAP external attachments are allowed, (IMAP: for
> > example). We and 2445 have no such restriction. So the only
> > checking could be for MIME object that are inline or packaged
> > in the same MIME object could be checked.
> 
> What about CAP non-external ATTACHments (ie: a CID to a previously
> sent REQUESTs ATTACHment)?  (This seems to be something John is keen
> on stressing in the multipart discussion...)

If you mean that OBJECT-1 has body part- "bp-1" and OBJECT-2 uses
a MID of "OBJECT-1/bp-1", that is valid MIME.

So the question becomes, should the CS keep a reference counter?
I would say it can, but it is not required to do so. The same
is true with an MUA. An MUA can contain a body part with a MID
to another body part in another message, it is still valid MIME
object, and the MID is still valid. It's just that what it points to
may have been erased. If the MUA were to do reference counts, then
it could be argued that is a good or bad thing. Bad because the
user may have intended it to go away and the 'no such MID' error
may be a good thing depending on the application.

I would say not to do reference counting on MIDs and CIDs.

In other applications, keeping a reference counter and doing
garbage collection may be a good thing.

> I do agree that only safe way to send the ATTACH is to put it into a
> same MIME object/stream (see previous postings for why).

I agree.

> > > >   4) How can a CUA let a user know that an event has an
> attachment
> > > >      without downloading it? This can allow the attachment to be
> > > >      downloaded only if the users "clicks" on it.
> > >
> > > No clue how.  Id love to see a good way for the CUA to get info
> > > about ATTACHments (inlined or not) and have some way to do this...
> >
> > Looking for proposals :-)
> 
> That sounds like you have an idea but no text (or are crafting text as
> I respond....)  Im mulling over an idea but nothing I want to throw
> out for the wolves just yet.

Your right, as soon as I sent the email, I remembered how to
do that and posted it.
--------------83E5C40EA134C1A9E38E41D8
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------83E5C40EA134C1A9E38E41D8--



From owner-ietf-calendar@mail.imc.org  Wed Sep 11 16:28:33 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23634
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 16:28:33 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BKKXc02077
	for ietf-calendar-bks; Wed, 11 Sep 2002 13:20:33 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BKKWk02071
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 13:20:32 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8BKKRdn001503
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 13:20:30 -0700
Message-ID: <3D7FA484.3A0F12B2@Royer.com>
Date: Wed, 11 Sep 2002 14:16:04 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <3D7E1122.70716473@oracle.com> <3D7E2DB2.284A9556@Royer.com>
		<3D7E3B30.2D2B9B7C@oracle.com> <3D7E52A6.2456F82C@Royer.com>
		<3D7F407A.55C6AAEB@oracle.com>  <3D7F6CE1.D5D5AEC4@Royer.com> <1031768117.19167.49.camel@c-1241.in.steltor.com>
Content-Type: multipart/mixed;
 boundary="------------A847BB84C172E76DB56BC8C5"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------A847BB84C172E76DB56BC8C5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Patrice Lapierre wrote:
types for all VEVENTs.
> >
> > -->NOTE: The current ABNF is busted - we somehow dropped parameters
> > from being selectable.
> 
> As far as I know parameters were never individually selectable.

You may be right, I thought it was.

> It could be a nice feature for attachments. However we must realize
> that this feature would allow a CAP server to return invalid iCalendar
> objects, since the empty value is not accepted by all data types.
> 
> For example, consider:
> 
>   SELECT PARAM( DTSTART, TZID ) FROM VEVENT
> 
> I would expect the CS to return only the TZID parameter
> of the DTSTART property but not the value.
> 
> e.g.,
> 
>    VEVENT:BEGIN
>    DTSTART;TZID=US-Eastern:
>    VEVENT:END

Does anyone have any problem with this behavior? If not
I'll add text.

Also if a CUA were to ask for:

	SELECT DTSTART,PARAM(DTSTART, TZID) FROM VEVENT

They they would get back the DTSTART value including
ALL of the parameters and parameter values. And exactly
as many responses that matched properties, as in:

	SELECT some-prop,PARAM(somp-prop, foo) FROM VEVENT

	Would return Y number of some-prop properties and all
	of their values (Where Y == the number of 'some-prop' 
	properties in the matching VEVENTs). So if there were
	exactly one 'some-prop' properties and you supplied the
        above select, you would get:

		BEGIN:VEVENT
		some-prop;param-a=xx,foo=zz:value
		END:VEVENT

	And NOT:

	
		BEGIN:VEVENT
		some-prop;param-a=xx,foo=zz:value
		some-prop;foo=zz:
		END:VEVENT

Any objections?

> That being said, it might not be a huge issue since the CUA has
> to explicitly request it.
--------------A847BB84C172E76DB56BC8C5
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------A847BB84C172E76DB56BC8C5--



From owner-ietf-calendar@mail.imc.org  Wed Sep 11 17:37:55 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25797
	for <calsch-archive@lists.ietf.org>; Wed, 11 Sep 2002 17:37:54 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8BLERV05088
	for ietf-calendar-bks; Wed, 11 Sep 2002 14:14:27 -0700 (PDT)
Received: from eeyore.jsoft.com (24-240-234-245.charter.com [24.240.234.245])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BLEQk05084
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 14:14:26 -0700 (PDT)
Received: from jsoft.com (IDENT:r+Vkhi5IFLMleradlR9qv27o+iH7ep6n@eeyore.jsoft.com [192.168.0.46])
	by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g8BL8So12291
	for <ietf-calendar@imc.org>; Wed, 11 Sep 2002 16:08:28 -0500
Message-ID: <3D7FB0CC.1000104@jsoft.com>
Date: Wed, 11 Sep 2002 16:08:28 -0500
From: Gary Frederick <gary.frederick@jsoft.com>
Organization: Jefferson Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <20020911113243.GD91461@inet.it>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


I like the direction this gives. As I read it, it clarifies that any application talks text/calendar while letting the big guys support more.

>  1.2 multipart/related
> 
> If the exchanged packets contain multipart/related payload, they MUST
> contain at least one text/calendar parts.

I feel there may still be a lot of conversation before all the 'parts' are sorted out.

I think Andrea's proposal fits with what Doug has been saying. ???


Gary



Andrea Campi wrote:
> Hi all,
> 
> I'm writing this as a proposal to help focus the discussion and above
> all make sure I make my point clear. I think at least a few people
> agree on my point of view, so I hope nobody finds this out of place.
> I'm not asking to include this text in the draft unless people agree
> on all of it. And please excuse my english but I'm not a native
> speaker.
> 
> 
> 
>  1 Multipart in CAP	[note: addition/revision to 3.3.1 in current draft]
> 
> The BEEP data exchanged in CAP may take different forms depending on
> the data being exchanged and the capabilities of the CUA and the CS.
> 
> If data can be sent in different forms, it is advisable to send it
> as text/calendar. In particular, most commands can be sent as
> test/calendar.
> 
> 
>  1.1 text/calendar
> 
> If the payload of a BEEP packet is of type text/calendar, it MUST
> conform to [iCAL] iCalendar format. This is the only format which
> all CAP implementations MUST accept.
> 
>  1.2 multipart/related
> 
> If the exchanged packets contain multipart/related payload, they MUST
> contain at least one text/calendar parts. If it contains more than
> one, they are processed in the same order as they appear [note: I
> have no strong opinion on this point]. Data in text/calendar parts
> MUST conform to [iCAL] iCalendar format.
> If a CUA or a CS don't support this form, they MUST respond with an
> appropriate REQUEST-STATUS.
> 
> [note: obviously, text/calendar MAY be inside text/alternative, and
> parts with unknown MIME types can be thrown away. I don't think we
> need to state this here]
> 
> If needed, additional data can be transmitted in addidional body
> parts using the appropriate MIME type; in particular, this can be
> used for attachments. Additional body parts are referred to using
> CID: etc.
> 
>  2 Multipart negotiation
> 
> A CUA and a CS SHOULD negotiate the level of multipart support.
> This can be done using the GET-CAPABILITY command [note: we must
> add a property for this].
> A party should assume the other party can't do multipart, and send
> a GET-CAPABILITY command as text/calendar. If the answer states that
> the other party supports multipart, it can send subsequent commands
> using the appropriate form.
> As an alternative, a party may opt to start using multipart and switch
> to the simpler text/calendar form if it receives an error.
> 
>  3 Considerations
> 
>  3.1 Graceful degradation
> 
> If both parties support multipart, each party may opt to use the
> encoding it prefers. However, text/calendar support is mandatory,
> which in particular means a CS MUST use text/calendar in replies
> to commands if the party only supports that form, with no loss of
> data except as indicated in 3.2.
> In particular, if the CUA only supports text/calendar:
> 
>  - all replies to commands with multiple targets or multiple queries, as
> well as replies containing separate components with different METHODs,
> must be sent with different iCalendar objects in the same text/calendar
> 
> [note: add more here if we want to. I know this is already present
> in iCal]
> 
>  3.2 Limitations
> 
>  3.2.1 cid: URI
> 
> A CUA or a CS which doesn't support multipart can't properly handle
> properties with a cid: URI value; this affects ATTACH properties and
> any property which allows the ALTREP parameter.
> 
> A limited CUA SHOULD inform the user that there is an attachment but
> it is not able to access it. It should also provide alternative ways
> to attach files to outgoing components. One method would be to store
> the file on an appropriate file store and store the URI.
> 
> A limited CS SHOULD try not to lose ATTACHments. One method would be
> to provide an iMIP+CAP client that stores attachments on any appropriate
> file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
> ATTACH properties to reference the appropriate URI. It is advisable
> that CS which have no limitations, but want to support clients with
> limited capabilities, do the same conversion, either at time or
> retrieval time.
> 
> 
> 
> 
> A final note: I purposefully don't address the problem of a limited
> CUA or CS not being able to properly process an iMIP message. As some
> people noted on the list, a CUA does not HAVE to know about iMIP, nor
> does a CS; in fact, a CUA doesn't have to deal with email at all.
> 
> If the implementator wants iMIP support it can still use the same
> approach as in 3.2.1, that is provide an iMIP+CAP client to do the
> processing. This would probably take the form of a filter inside a
> MTA or MUA application.
> 
> 
> I think this proposal addresses all concerns presented on the list
> by advocates of both approaches. An implementor is free to choose
> to support limited or complete functionality without limiting the
> user. At the same time, this doesn't in any way (that I know of)
> violate or restrict any existent RFC.
> 
> I expect that complete applications like Outlook or Ximian Evolution
> would support the whole enchilada (they have to, anyway), while light
> clients (cell phones, CGI interfaces etc) can be much simpler.
> 
> 
> Bye,
> 	Andrea
> 



From owner-ietf-calendar@mail.imc.org  Thu Sep 12 08:49:26 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21563
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 08:49:26 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CCfY627553
	for ietf-calendar-bks; Thu, 12 Sep 2002 05:41:34 -0700 (PDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CCfWk27547
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 05:41:32 -0700 (PDT)
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8CCfS710797
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 05:41:28 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8CCfRp10786
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 05:41:27 -0700 (PDT)
Received: from c-1241.in.steltor.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8CCfQO17679
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 06:41:27 -0600 (MDT)
Subject: Selection of parameters in CAP-QL (was: [Fwd: How To Handle
	Attachments])
From: Patrice Lapierre <patrice.lapierre@oracle.com>
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
In-Reply-To: <3D7FA484.3A0F12B2@Royer.com>
References: <3D7E1122.70716473@oracle.com> <3D7E2DB2.284A9556@Royer.com>
	<3D7E3B30.2D2B9B7C@oracle.com> <3D7E52A6.2456F82C@Royer.com>
	<3D7F407A.55C6AAEB@oracle.com>  <3D7F6CE1.D5D5AEC4@Royer.com>
	<1031768117.19167.49.camel@c-1241.in.steltor.com> 
	<3D7FA484.3A0F12B2@Royer.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 
Date: 12 Sep 2002 08:37:44 -0400
Message-Id: <1031834265.19167.117.camel@c-1241.in.steltor.com>
Mime-Version: 1.0
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


The addition of parameters in the select clause of CAP-QL 
will also impacts VCARs. They'll be able to target individual
parameters.

e.g.,	BEGIN:VCAR
        CARID:UPDATEPARTSTATUS
        BEGIN:VRIGHT
        GRANT:*
        PERMISSION:MODIFY
        SCOPE:SELECT PARAM(ATTENDEE,PARTSTAT) FROM VEVENT
         WHERE ATTENDEE = SELF()
         AND ORGANIZER = CURRENT-TARGET()
         AND STATE() = 'BOOKED'
         RESTRICTION:SELECT * FROM VEVENT
         WHERE ATTENDEE = SELF()
        END:VRIGHT
        END:VCAR

For completeness it seems that we should also allow
the selection of the property value without implicitly
including all the parameters.

e.g., something like  SELECT PROPVALUE(ATTENDEE) FROM ...


Now if a VCAR can target a portion of a property, the 
the SEARCH command may return incomplete properties.

This may cause problems with the UPDATE command, since a 
user may not be able provide the complete property in the 
"before" section. A workaround could be to consider only 
values that are accessible to the user when matching 
the before section of an update.

What do you think?
    
--
Patrice.


On Wed, 2002-09-11 at 16:16, Doug Royer wrote:
> Patrice Lapierre wrote:
> types for all VEVENTs.
> > >
> > > -->NOTE: The current ABNF is busted - we somehow dropped parameters
> > > from being selectable.
> > 
> > As far as I know parameters were never individually selectable.
> 
> You may be right, I thought it was.
> 
> > It could be a nice feature for attachments. However we must realize
> > that this feature would allow a CAP server to return invalid iCalendar
> > objects, since the empty value is not accepted by all data types.
> > 
> > For example, consider:
> > 
> >   SELECT PARAM( DTSTART, TZID ) FROM VEVENT
> > 
> > I would expect the CS to return only the TZID parameter
> > of the DTSTART property but not the value.
> > 
> > e.g.,
> > 
> >    VEVENT:BEGIN
> >    DTSTART;TZID=US-Eastern:
> >    VEVENT:END
> 
> Does anyone have any problem with this behavior? If not
> I'll add text.
> 
> Also if a CUA were to ask for:
> 
> 	SELECT DTSTART,PARAM(DTSTART, TZID) FROM VEVENT
> 
> They they would get back the DTSTART value including
> ALL of the parameters and parameter values. And exactly
> as many responses that matched properties, as in:
> 
> 	SELECT some-prop,PARAM(somp-prop, foo) FROM VEVENT
> 
> 	Would return Y number of some-prop properties and all
> 	of their values (Where Y == the number of 'some-prop' 
> 	properties in the matching VEVENTs). So if there were
> 	exactly one 'some-prop' properties and you supplied the
>         above select, you would get:
> 
> 		BEGIN:VEVENT
> 		some-prop;param-a=xx,foo=zz:value
> 		END:VEVENT
> 
> 	And NOT:
> 
> 	
> 		BEGIN:VEVENT
> 		some-prop;param-a=xx,foo=zz:value
> 		some-prop;foo=zz:
> 		END:VEVENT
> 
> Any objections?
> 
> > That being said, it might not be a huge issue since the CUA has
> > to explicitly request it.





From owner-ietf-calendar@mail.imc.org  Thu Sep 12 11:09:17 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26123
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 11:09:16 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CEct504411
	for ietf-calendar-bks; Thu, 12 Sep 2002 07:38:55 -0700 (PDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CEcsk04405
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 07:38:54 -0700 (PDT)
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8CEcoe03621
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 07:38:50 -0700 (PDT)
Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8CEcoC03612;
	Thu, 12 Sep 2002 07:38:50 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8CEcmN00493;
	Thu, 12 Sep 2002 08:38:48 -0600 (MDT)
Message-ID: <3D80A6F7.A8AD7DEB@oracle.com>
Date: Thu, 12 Sep 2002 10:38:47 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: Bruce_Kahn@notesdev.ibm.com
CC: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
References: <OFF86E6429.D49EC96D-ON85256C30.00630521-85256C30.00653E91@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> George wrote on 09/10/2002 11:34:58 AM:
> >   1) How can a CUA get all properties of a component except an
> >      attachment, which may be very big?
> 
> Dont ask for the ATTACH property to be returned on the query??  Its unclear how to say "Only give me the VEVENT and no ATTACHments (or ALTREPs, etc)" but perhaps Doug or John can correct me and
> point this out.
> 
> Along the same vein of questioning: If the original ATTACHment is NOT inlined then is there any way for me to ask for the ATTACHments value but NOT the actual contents?  Also, is there any way for
> the CUA to tell apriori If the ATTACHment is inlined so it knows to ask the previous question instead of just saying "Dont give me any ATTACHments"?
> 
> >   2) How do we delete or modify an attachment if a component
> >      has multiple attachments?
> 
> Each ATTACHment must have a CID that is unique (unless you wanted to attach multiple copies of the same file!).  As such, you can uniquely identify them based on their CID value (sic).  As for
> updating/removing them, thats a total haze to me.  I can suggest ways that Ive seen it done for MHTML messages but those kinds of solutions basically involve resaving the entire stream and removing
> the old copy(s).  No "delta" operations there...
> 
> >                                CAP draft specifies that the
> >      CUA can specify a part of the attachment such that it
> >      is uniquely identified. That means that the CUA must download
> >      the entire attachment, upload part of it in the MODIFY command,
> >      and upload the entire new attachment.
> 
> If the CUA has a local copy then it doesnt have to download it all to modify it.   If not then yes it has to download all, say, 25M of the file to modify it safely.  As for sending data back up its
> not clear that the entire updated ATTACHment must be sent back up.  If you can uniquely identify it via its CID then you could possibly just send the updates.

  Yes, it can work in the case that the attachment has a CID, but will if the attachment
is inline, then replacing an attachment with another can require much uploading and
downloading.  

  However, using inline attachments is not recommended. Even if a CUA gives the CS an inline
attachment, the CS can return it with a CID and not inline. This way modifications to
attachments can be easily done.

  Should we have text in the CAP draft recommending how attachments should be
handled?

> 
> Of course this could lead to some nasty/corrupted files if both you and your AA modify the same ZIP archive and dont actually have a way to detect that the 'original' copy has changed to a newer one
> (when the slower of the two of you try to do the MODIFY).  I strongly doubt you want to build in some kind of locking or checkout mechanism (ala WebDAV) into this or at least I hope not...  So whats
> the solution??...
> 
> >                                              How will the CUA know
> >      up to now many bytes of the old attachment uniquely identifies
> >      it.
> 
> Its not a function of the bytes you send back (or is it??); it should be a function of the CID.  If you allow CID reuse (ie: multiple ATTACHments of the same file and reuse of the CID thereof) then
> this wont work.  If you assigned a new CID per ATTACHment (even on duplicates) then you should be all set.

  If the attachment were inline it can be a function of the number of bytes.

> 
> >   3) In section 9.5 (MODIFY Command):
> >
> >         The ATTACHMENT value supplied by the CUA MUST BE
> >         valid encoded information.
> >
> >      What does this mean? Does it mean that the encoding must match
> >      the "ENCODING" parameter? Can this always be verified?
> 
> Sounds like the its talking about the CID value of the ATTACH property.  It could also be talking about an inlined ATTACHment where the data is all there and iCalendar has mandated particular
> property parameters be present.
> 
> I would hope that you dont allow an ATTACHment reference to a CID thats not available.  There may be a forward reference to a CID in the iCalendar data but once you scan the MIME stream you can tell
> if the CID is there or not.  If not, some consistant course of action should happen (ie: remove the ATTACH, send an error code to the CUA, etc).
> 
> >   4) How can a CUA let a user know that an event has an attachment
> >      without downloading it? This can allow the attachment to be
> >      downloaded only if the users "clicks" on it.
> 
> No clue how.  Id love to see a good way for the CUA to get info about ATTACHments (inlined or not) and have some way to do this...
> 
> Bruce
> ===========================================================================
> Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
> Messaging & Collaboration                 Phone: 978.399.6496
> IBM Software Group                         FAX: and nothing but the FAX...
> Standard disclaimers apply, even where prohibited by law...


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 11:54:30 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27354
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 11:54:29 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CFm6w08665
	for ietf-calendar-bks; Thu, 12 Sep 2002 08:48:06 -0700 (PDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CFm5k08660
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 08:48:05 -0700 (PDT)
Received: from inet-mail3.oracle.com (localhost [127.0.0.1])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8CFm1P27593
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 08:48:01 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8CFm1R27586
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 08:48:01 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8CFm0v08894
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 09:48:00 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8CFlxf08866
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 09:47:59 -0600 (MDT)
Message-ID: <3D80B72E.B1B55EEA@oracle.com>
Date: Thu, 12 Sep 2002 11:47:58 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <20020911113243.GD91461@inet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



I do like the proposal. I have a few comments (see below).

Andrea Campi wrote:
> 
> Hi all,
> 
> I'm writing this as a proposal to help focus the discussion and above
> all make sure I make my point clear. I think at least a few people
> agree on my point of view, so I hope nobody finds this out of place.
> I'm not asking to include this text in the draft unless people agree
> on all of it. And please excuse my english but I'm not a native
> speaker.
> 
>  1 Multipart in CAP     [note: addition/revision to 3.3.1 in current draft]
> 
> The BEEP data exchanged in CAP may take different forms depending on
> the data being exchanged and the capabilities of the CUA and the CS.
> 
> If data can be sent in different forms, it is advisable to send it
> as text/calendar. In particular, most commands can be sent as
> test/calendar.
> 
>  1.1 text/calendar
> 
> If the payload of a BEEP packet is of type text/calendar, it MUST
> conform to [iCAL] iCalendar format. This is the only format which
> all CAP implementations MUST accept.
> 
>  1.2 multipart/related
> 
> If the exchanged packets contain multipart/related payload, they MUST
> contain at least one text/calendar parts. If it contains more than
> one, they are processed in the same order as they appear [note: I
> have no strong opinion on this point]. Data in text/calendar parts
> MUST conform to [iCAL] iCalendar format.

  Should we restrict it to one text/calendar part only? Is there a reason
to have more than one part? By specifying only one way, it may make
interoperability easier?

> If a CUA or a CS don't support this form, they MUST respond with an
> appropriate REQUEST-STATUS.

  We would need to find a new response code for this.
  I think we still need to fix the response codes in CAP.
  Doug, I believe we decided to do this once CAP is close to
  being finalized?
  
> 
> [note: obviously, text/calendar MAY be inside text/alternative, and
> parts with unknown MIME types can be thrown away. I don't think we
> need to state this here]
> 
> If needed, additional data can be transmitted in addidional body
> parts using the appropriate MIME type; in particular, this can be
> used for attachments. Additional body parts are referred to using
> CID: etc.
> 
>  2 Multipart negotiation
> 
> A CUA and a CS SHOULD negotiate the level of multipart support.
> This can be done using the GET-CAPABILITY command [note: we must
> add a property for this].
> A party should assume the other party can't do multipart, and send
> a GET-CAPABILITY command as text/calendar. If the answer states that
> the other party supports multipart, it can send subsequent commands
> using the appropriate form.
> As an alternative, a party may opt to start using multipart and switch
> to the simpler text/calendar form if it receives an error.
> 
>  3 Considerations
> 
>  3.1 Graceful degradation
> 
> If both parties support multipart, each party may opt to use the
> encoding it prefers. However, text/calendar support is mandatory,
> which in particular means a CS MUST use text/calendar in replies
> to commands if the party only supports that form, with no loss of
> data except as indicated in 3.2.
> In particular, if the CUA only supports text/calendar:
> 
>  - all replies to commands with multiple targets or multiple queries, as
> well as replies containing separate components with different METHODs,
> must be sent with different iCalendar objects in the same text/calendar
> 
> [note: add more here if we want to. I know this is already present
> in iCal]
> 
>  3.2 Limitations
> 
>  3.2.1 cid: URI
> 
> A CUA or a CS which doesn't support multipart can't properly handle
> properties with a cid: URI value; this affects ATTACH properties and
> any property which allows the ALTREP parameter.
> 
> A limited CUA SHOULD inform the user that there is an attachment but
> it is not able to access it. It should also provide alternative ways
> to attach files to outgoing components. One method would be to store
> the file on an appropriate file store and store the URI.

  Is this needed? Can it be a MAY?

> 
> A limited CS SHOULD try not to lose ATTACHments. One method would be
> to provide an iMIP+CAP client that stores attachments on any appropriate
> file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
> ATTACH properties to reference the appropriate URI. It is advisable
> that CS which have no limitations, but want to support clients with
> limited capabilities, do the same conversion, either at time or
> retrieval time.

  Is this needed? Can it be a MAY?

> 
> A final note: I purposefully don't address the problem of a limited
> CUA or CS not being able to properly process an iMIP message. As some
> people noted on the list, a CUA does not HAVE to know about iMIP, nor
> does a CS; in fact, a CUA doesn't have to deal with email at all.
> 
> If the implementator wants iMIP support it can still use the same
> approach as in 3.2.1, that is provide an iMIP+CAP client to do the
> processing. This would probably take the form of a filter inside a
> MTA or MUA application.
> 
> I think this proposal addresses all concerns presented on the list
> by advocates of both approaches. An implementor is free to choose
> to support limited or complete functionality without limiting the
> user. At the same time, this doesn't in any way (that I know of)
> violate or restrict any existent RFC.
> 
> I expect that complete applications like Outlook or Ximian Evolution
> would support the whole enchilada (they have to, anyway), while light
> clients (cell phones, CGI interfaces etc) can be much simpler.
> 
> Bye,
>         Andrea
> 
> --
> Andrea Campi                              mailto:a.campi@inet.it
> I.NET S.p.A.                              http://www.inet.it
> Direzione Tecnica - R&D                   phone: +39 02 32863 ext 1
> v. Darwin, 85 - I-20019                   fax: +39 02 32863 ext 7705
> Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 11:59:55 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27490
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 11:59:53 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CFmwd08789
	for ietf-calendar-bks; Thu, 12 Sep 2002 08:48:58 -0700 (PDT)
Received: from server1.egenconsulting.com ([208.31.106.94])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CFmtk08774
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 08:48:55 -0700 (PDT)
To: Andrea Campi <a.campi@inet.it>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: Proposal about multipart etc
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFB9294FE3.DA029C11-ON85256C32.0056BFCA@egenconsulting.com>
From: pregen@egenconsulting.com
Date: Thu, 12 Sep 2002 11:48:54 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at
 09/12/2002 11:48:57 AM,
	Serialize complete at 09/12/2002 11:48:57 AM
Content-Type: multipart/alternative; boundary="=_alternative 0056E03D85256C32_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0056E03D85256C32_=
Content-Type: text/plain; charset="us-ascii"

Andrea, I like your proposal a lot.  it's clear and concise.  Anyone else 
on the list - please respond to Andrea with yoru comments.  We always like 
it when someone goes to this length to provide actual text ( 8-) ) that we 
can incorporate in a draft document.  I know you are out there - there are 
over 300 people subscribed to this list - let's hear from you! Thanks.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652




Andrea Campi <a.campi@inet.it>
Sent by: owner-ietf-calendar@mail.imc.org
09/11/2002 07:32

 
        To:     ietf-calendar@imc.org
        cc: 
        Subject:        Proposal about multipart etc



Hi all,

I'm writing this as a proposal to help focus the discussion and above
all make sure I make my point clear. I think at least a few people
agree on my point of view, so I hope nobody finds this out of place.
I'm not asking to include this text in the draft unless people agree
on all of it. And please excuse my english but I'm not a native
speaker.



 1 Multipart in CAP              [note: addition/revision to 3.3.1 in 
current draft]

The BEEP data exchanged in CAP may take different forms depending on
the data being exchanged and the capabilities of the CUA and the CS.

If data can be sent in different forms, it is advisable to send it
as text/calendar. In particular, most commands can be sent as
test/calendar.


 1.1 text/calendar

If the payload of a BEEP packet is of type text/calendar, it MUST
conform to [iCAL] iCalendar format. This is the only format which
all CAP implementations MUST accept.

 1.2 multipart/related

If the exchanged packets contain multipart/related payload, they MUST
contain at least one text/calendar parts. If it contains more than
one, they are processed in the same order as they appear [note: I
have no strong opinion on this point]. Data in text/calendar parts
MUST conform to [iCAL] iCalendar format.
If a CUA or a CS don't support this form, they MUST respond with an
appropriate REQUEST-STATUS.

[note: obviously, text/calendar MAY be inside text/alternative, and
parts with unknown MIME types can be thrown away. I don't think we
need to state this here]

If needed, additional data can be transmitted in addidional body
parts using the appropriate MIME type; in particular, this can be
used for attachments. Additional body parts are referred to using
CID: etc.

 2 Multipart negotiation

A CUA and a CS SHOULD negotiate the level of multipart support.
This can be done using the GET-CAPABILITY command [note: we must
add a property for this].
A party should assume the other party can't do multipart, and send
a GET-CAPABILITY command as text/calendar. If the answer states that
the other party supports multipart, it can send subsequent commands
using the appropriate form.
As an alternative, a party may opt to start using multipart and switch
to the simpler text/calendar form if it receives an error.

 3 Considerations

 3.1 Graceful degradation

If both parties support multipart, each party may opt to use the
encoding it prefers. However, text/calendar support is mandatory,
which in particular means a CS MUST use text/calendar in replies
to commands if the party only supports that form, with no loss of
data except as indicated in 3.2.
In particular, if the CUA only supports text/calendar:

 - all replies to commands with multiple targets or multiple queries, as
well as replies containing separate components with different METHODs,
must be sent with different iCalendar objects in the same text/calendar

[note: add more here if we want to. I know this is already present
in iCal]

 3.2 Limitations

 3.2.1 cid: URI

A CUA or a CS which doesn't support multipart can't properly handle
properties with a cid: URI value; this affects ATTACH properties and
any property which allows the ALTREP parameter.

A limited CUA SHOULD inform the user that there is an attachment but
it is not able to access it. It should also provide alternative ways
to attach files to outgoing components. One method would be to store
the file on an appropriate file store and store the URI.

A limited CS SHOULD try not to lose ATTACHments. One method would be
to provide an iMIP+CAP client that stores attachments on any appropriate
file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
ATTACH properties to reference the appropriate URI. It is advisable
that CS which have no limitations, but want to support clients with
limited capabilities, do the same conversion, either at time or
retrieval time.




A final note: I purposefully don't address the problem of a limited
CUA or CS not being able to properly process an iMIP message. As some
people noted on the list, a CUA does not HAVE to know about iMIP, nor
does a CS; in fact, a CUA doesn't have to deal with email at all.

If the implementator wants iMIP support it can still use the same
approach as in 3.2.1, that is provide an iMIP+CAP client to do the
processing. This would probably take the form of a filter inside a
MTA or MUA application.


I think this proposal addresses all concerns presented on the list
by advocates of both approaches. An implementor is free to choose
to support limited or complete functionality without limiting the
user. At the same time, this doesn't in any way (that I know of)
violate or restrict any existent RFC.

I expect that complete applications like Outlook or Ximian Evolution
would support the whole enchilada (they have to, anyway), while light
clients (cell phones, CGI interfaces etc) can be much simpler.


Bye,
                 Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D                                            phone: 
+39 02 32863 ext 1
v. Darwin, 85 - I-20019                                            fax: 
+39 02 32863 ext 7705
Settimo Milanese (MI), Italy



--=_alternative 0056E03D85256C32_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Andrea, I like your proposal a lot. &nbsp;it's clear and concise. &nbsp;Anyone else on the list - please respond to Andrea with yoru comments. &nbsp;We always like it when someone goes to this length to provide actual text ( 8-) ) that we can incorporate in a draft document. &nbsp;I know you are out there - there are over 300 people subscribed to this list - let's hear from you! Thanks.<br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Andrea Campi &lt;a.campi@inet.it&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: owner-ietf-calendar@mail.imc.org</font>
<p><font size=1 face="sans-serif">09/11/2002 07:32</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;ietf-calendar@imc.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Proposal about multipart etc</font></table>
<br>
<br>
<br><font size=2><tt><br>
Hi all,<br>
<br>
I'm writing this as a proposal to help focus the discussion and above<br>
all make sure I make my point clear. I think at least a few people<br>
agree on my point of view, so I hope nobody finds this out of place.<br>
I'm not asking to include this text in the draft unless people agree<br>
on all of it. And please excuse my english but I'm not a native<br>
speaker.<br>
<br>
<br>
<br>
 1 Multipart in CAP &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [note: addition/revision to 3.3.1 in current draft]<br>
<br>
The BEEP data exchanged in CAP may take different forms depending on<br>
the data being exchanged and the capabilities of the CUA and the CS.<br>
<br>
If data can be sent in different forms, it is advisable to send it<br>
as text/calendar. In particular, most commands can be sent as<br>
test/calendar.<br>
<br>
<br>
 1.1 text/calendar<br>
<br>
If the payload of a BEEP packet is of type text/calendar, it MUST<br>
conform to [iCAL] iCalendar format. This is the only format which<br>
all CAP implementations MUST accept.<br>
<br>
 1.2 multipart/related<br>
<br>
If the exchanged packets contain multipart/related payload, they MUST<br>
contain at least one text/calendar parts. If it contains more than<br>
one, they are processed in the same order as they appear [note: I<br>
have no strong opinion on this point]. Data in text/calendar parts<br>
MUST conform to [iCAL] iCalendar format.<br>
If a CUA or a CS don't support this form, they MUST respond with an<br>
appropriate REQUEST-STATUS.<br>
<br>
[note: obviously, text/calendar MAY be inside text/alternative, and<br>
parts with unknown MIME types can be thrown away. I don't think we<br>
need to state this here]<br>
<br>
If needed, additional data can be transmitted in addidional body<br>
parts using the appropriate MIME type; in particular, this can be<br>
used for attachments. Additional body parts are referred to using<br>
CID: etc.<br>
<br>
 2 Multipart negotiation<br>
<br>
A CUA and a CS SHOULD negotiate the level of multipart support.<br>
This can be done using the GET-CAPABILITY command [note: we must<br>
add a property for this].<br>
A party should assume the other party can't do multipart, and send<br>
a GET-CAPABILITY command as text/calendar. If the answer states that<br>
the other party supports multipart, it can send subsequent commands<br>
using the appropriate form.<br>
As an alternative, a party may opt to start using multipart and switch<br>
to the simpler text/calendar form if it receives an error.<br>
<br>
 3 Considerations<br>
<br>
 3.1 Graceful degradation<br>
<br>
If both parties support multipart, each party may opt to use the<br>
encoding it prefers. However, text/calendar support is mandatory,<br>
which in particular means a CS MUST use text/calendar in replies<br>
to commands if the party only supports that form, with no loss of<br>
data except as indicated in 3.2.<br>
In particular, if the CUA only supports text/calendar:<br>
<br>
 - all replies to commands with multiple targets or multiple queries, as<br>
well as replies containing separate components with different METHODs,<br>
must be sent with different iCalendar objects in the same text/calendar<br>
<br>
[note: add more here if we want to. I know this is already present<br>
in iCal]<br>
<br>
 3.2 Limitations<br>
<br>
 3.2.1 cid: URI<br>
<br>
A CUA or a CS which doesn't support multipart can't properly handle<br>
properties with a cid: URI value; this affects ATTACH properties and<br>
any property which allows the ALTREP parameter.<br>
<br>
A limited CUA SHOULD inform the user that there is an attachment but<br>
it is not able to access it. It should also provide alternative ways<br>
to attach files to outgoing components. One method would be to store<br>
the file on an appropriate file store and store the URI.<br>
<br>
A limited CS SHOULD try not to lose ATTACHments. One method would be<br>
to provide an iMIP+CAP client that stores attachments on any appropriate<br>
file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite<br>
ATTACH properties to reference the appropriate URI. It is advisable<br>
that CS which have no limitations, but want to support clients with<br>
limited capabilities, do the same conversion, either at time or<br>
retrieval time.<br>
<br>
<br>
<br>
<br>
A final note: I purposefully don't address the problem of a limited<br>
CUA or CS not being able to properly process an iMIP message. As some<br>
people noted on the list, a CUA does not HAVE to know about iMIP, nor<br>
does a CS; in fact, a CUA doesn't have to deal with email at all.<br>
<br>
If the implementator wants iMIP support it can still use the same<br>
approach as in 3.2.1, that is provide an iMIP+CAP client to do the<br>
processing. This would probably take the form of a filter inside a<br>
MTA or MUA application.<br>
<br>
<br>
I think this proposal addresses all concerns presented on the list<br>
by advocates of both approaches. An implementor is free to choose<br>
to support limited or complete functionality without limiting the<br>
user. At the same time, this doesn't in any way (that I know of)<br>
violate or restrict any existent RFC.<br>
<br>
I expect that complete applications like Outlook or Ximian Evolution<br>
would support the whole enchilada (they have to, anyway), while light<br>
clients (cell phones, CGI interfaces etc) can be much simpler.<br>
<br>
<br>
Bye,<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Andrea<br>
<br>
-- <br>
Andrea Campi &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;mailto:a.campi@inet.it<br>
I.NET S.p.A. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;http://www.inet.it<br>
Direzione Tecnica - R&amp;D &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; phone: +39 02 32863 ext 1<br>
v. Darwin, 85 - I-20019 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; fax: +39 02 32863 ext 7705<br>
Settimo Milanese (MI), Italy<br>
</tt></font>
<br>
<br>
--=_alternative 0056E03D85256C32_=--


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 12:22:10 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28123
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 12:22:09 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CG6tV09863
	for ietf-calendar-bks; Thu, 12 Sep 2002 09:06:55 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CG6sk09859
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 09:06:54 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8CG6odn009925
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 09:06:54 -0700
Message-ID: <3D80BA87.6CBE459B@Royer.com>
Date: Thu, 12 Sep 2002 10:02:15 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <OFF86E6429.D49EC96D-ON85256C30.00630521-85256C30.00653E91@iris.com> <3D80A6F7.A8AD7DEB@oracle.com>
Content-Type: multipart/mixed;
 boundary="------------57E9E3E812690B5B22053F09"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------57E9E3E812690B5B22053F09
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

George Babics wrote:

> Yes, it can work in the case that the attachment has a CID, but will
> if the attachment is inline, then replacing an attachment with another
> can require much uploading and downloading.
> 
> However, using inline attachments is not recommended. Even if a CUA
> gives the CS an inline attachment, the CS can return it with a CID
> and not inline. This way modifications to attachments can be easily done.
> 
> Should we have text in the CAP draft recommending how attachments
> should be handled?

Some are going to prefer inline others CIDs. For small attachments
inline is fine, for huge attachments I would use a separate body parts.
If I want several components to ATTACH a small object, I could
use an FTP URI, IMAP URI, MID, or any other valid URI.

And you still have the same problem. The CU/CUA is not going to
know that it wants to delete or modify the ATTACH value
until it fetches it.

If the value is a CID, and the VQUERY has:

	SELECT ATTACH FROM VEVENT ...

I would have to allow for and expect that I could get
a MIME object with one or two body parts. One text/calendar,
the other the CID contents (if they exist - and they should).
If the value is a MID, I would expect one or two body parts - depending
if the CS has the contents of the MID or not. This is no different
than e-mail. Just because a MIME object contains a CID or MID (or
any other URI), does not mean they exist, it means that at once they
should have existed at one time.

If it is an inline, I would expect one body part - text/calendar
with the embedded inline ATTACH value.

Ether way, if you fetch an ATTACH value, you are going to
get the contents inline or in another body part (if in the CS).
--------------57E9E3E812690B5B22053F09
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------57E9E3E812690B5B22053F09--



From owner-ietf-calendar@mail.imc.org  Thu Sep 12 12:28:33 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28347
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 12:28:33 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8CGOF810606
	for ietf-calendar-bks; Thu, 12 Sep 2002 09:24:15 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CGODk10601
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 09:24:14 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8CGODdn010062
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 09:24:15 -0700
Message-ID: <3D80BE9C.125F5FB4@Royer.com>
Date: Thu, 12 Sep 2002 10:19:40 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Proposal about multipart etc
References: <20020911113243.GD91461@inet.it> <3D80B72E.B1B55EEA@oracle.com>
Content-Type: multipart/mixed;
 boundary="------------2E2B72D2A2C53AB9AB11AE84"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------2E2B72D2A2C53AB9AB11AE84
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

George Babics wrote:

> >  1.2 multipart/related
> >
> > If the exchanged packets contain multipart/related payload, they MUST
> > contain at least one text/calendar parts. If it contains more than
> > one, they are processed in the same order as they appear [note: I
> > have no strong opinion on this point]. Data in text/calendar parts
> > MUST conform to [iCAL] iCalendar format.
> 
>   Should we restrict it to one text/calendar part only? Is there a reason
> to have more than one part? By specifying only one way, it may make
> interoperability easier?

Why would that make it easier?

	while (more-text-calendar) {
		process-text-calendar
	}

> > If a CUA or a CS don't support this form, they MUST respond with an
> > appropriate REQUEST-STATUS.
> 
>   We would need to find a new response code for this.
>   I think we still need to fix the response codes in CAP.
>   Doug, I believe we decided to do this once CAP is close to
>   being finalized?

Yes, however there may not be any need for any error.
The other endpoint would know this from the MULTIPART capability.

I would think that is would be okay for the CS in that
case to convert any CIDs to inline, thus no error needed?
And if the URI value is not local, then just return it as a URI.

> >  3.2 Limitations
> >
> >  3.2.1 cid: URI
> >
> > A CUA or a CS which doesn't support multipart can't properly handle
> > properties with a cid: URI value; this affects ATTACH properties and
> > any property which allows the ALTREP parameter.
> >
> > A limited CUA SHOULD inform the user that there is an attachment but
> > it is not able to access it. It should also provide alternative ways
> > to attach files to outgoing components. One method would be to store
> > the file on an appropriate file store and store the URI.
> 
>   Is this needed? Can it be a MAY?

I agree - MAY. And I would also like the CS to have the
option of making it an inline ATTACH.
--------------2E2B72D2A2C53AB9AB11AE84
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------2E2B72D2A2C53AB9AB11AE84--



From owner-ietf-calendar@mail.imc.org  Thu Sep 12 12:53:42 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29142
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 12:53:42 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CGkdh11759
	for ietf-calendar-bks; Thu, 12 Sep 2002 09:46:39 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CGkck11754
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 09:46:38 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8CGkcdn010254
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 09:46:40 -0700
Message-ID: <3D80C3DD.B007BB0B@Royer.com>
Date: Thu, 12 Sep 2002 10:42:05 -0600
From: Doug Royer <Doug@royer.com>
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
CC: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <20020911113243.GD91461@inet.it>
Content-Type: multipart/mixed;
 boundary="------------3B822DFEB28B7415E5EF77AC"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------3B822DFEB28B7415E5EF77AC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:

>  3.2 Limitations
> 
>  3.2.1 cid: URI
> 
> A CUA or a CS which doesn't support multipart can't properly handle
> properties with a cid: URI value; this affects ATTACH properties and
> any property which allows the ALTREP parameter.
> 
> A limited CUA SHOULD inform the user that there is an attachment but
> it is not able to access it. It should also provide alternative ways
> to attach files to outgoing components. One method would be to store
> the file on an appropriate file store and store the URI.

I would think that if one endpoint does not support multipart,
then the other endpoint should convert all body part attachments
to inline - and not loose any data and transport them in one 
text/calendar object. We have size capabilities to limit
the size of objects. They will be storable or not.

I agree for ALTREP in a body part. The CUA must decide not
to store any of it, or break it up into what the CS can store
and inform the CU.

If a CUA can not support ALTREP in a body part, then the
CS should return the ALTREP exactly as it is in the
text/calendar object (CID:, ...) with no body part (return
a single text/calendar object). The CUA will know it can not do
multipart and can inform the user. The text/calendar object
can have an appropriate status code to let the CUA know
that the body part exists. CUAs are already going to have to deal
with non-existant CIDs, MIDs, FTPs, ... anyway.

> A limited CS SHOULD try not to lose ATTACHments. One method would be
> to provide an iMIP+CAP client that stores attachments on any appropriate
> file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
> ATTACH properties to reference the appropriate URI. It is advisable
> that CS which have no limitations, but want to support clients with
> limited capabilities, do the same conversion, either at time or
> retrieval time.

There is never any reason to loose attachments, they
can be converted to INLINE by the other endpoint. And
if they are rejected by the endpoint because of size or VCAR,
then they can not be trasported between those endpoints anyway.

And for ALTREP, if the CS can not store the body part, then
it is the CUAs responsibility to store the data or reject
the iCalendar object. We don't need any special protocol
for this, just inform the CU that the CS can not store
the body part contents for the ALTREP and let the CU decide.


--------------3B822DFEB28B7415E5EF77AC
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------3B822DFEB28B7415E5EF77AC--



From owner-ietf-calendar@mail.imc.org  Thu Sep 12 13:11:38 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29800
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 13:11:37 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CGtZp12224
	for ietf-calendar-bks; Thu, 12 Sep 2002 09:55:35 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CGtXk12219
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 09:55:34 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 5D0F91552D; Thu, 12 Sep 2002 18:55:34 +0200 (CEST)
Date: Thu, 12 Sep 2002 18:55:34 +0200
From: Andrea Campi <a.campi@inet.it>
To: George Babics <george.babics@oracle.com>
Cc: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
Message-ID: <20020912165534.GG20567@inet.it>
References: <20020911113243.GD91461@inet.it> <3D80B72E.B1B55EEA@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D80B72E.B1B55EEA@oracle.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Thu, Sep 12, 2002 at 11:47:58AM -0400, George Babics wrote:
> >  1.2 multipart/related
> > 
> > If the exchanged packets contain multipart/related payload, they MUST
> > contain at least one text/calendar parts. If it contains more than
> > one, they are processed in the same order as they appear [note: I
> > have no strong opinion on this point]. Data in text/calendar parts
> > MUST conform to [iCAL] iCalendar format.
> 
>   Should we restrict it to one text/calendar part only? Is there a reason
> to have more than one part? By specifying only one way, it may make
> interoperability easier?

As I noted, I don't feel very strongly about this, speaking in general.
I'd lean towards having only one text/calendar, but if somebody strongly
pushes in other direction, then so be it.

OTOH, I do feel that a command should be composed of only one
text/calendar containing one VCALENDAR object, thus limiting to exactly
one command per "transaction". But I definitely think that we should
first reach a consensus on the general format before.

> > If a CUA or a CS don't support this form, they MUST respond with an
> > appropriate REQUEST-STATUS.
> 
>   We would need to find a new response code for this.
>   I think we still need to fix the response codes in CAP.
>   Doug, I believe we decided to do this once CAP is close to
>   being finalized?

I agree. Also, if nobody else beats me to it, I think I will prepare
a proposal in a few days for the response codes every command can
generate (what can go wrong for each command); from then it should be
easier to build a final list.

> >  3.2.1 cid: URI
> > 
> > A CUA or a CS which doesn't support multipart can't properly handle
> > properties with a cid: URI value; this affects ATTACH properties and
> > any property which allows the ALTREP parameter.
> > 
> > A limited CUA SHOULD inform the user that there is an attachment but
> > it is not able to access it. It should also provide alternative ways
> > to attach files to outgoing components. One method would be to store
> > the file on an appropriate file store and store the URI.
> 
>   Is this needed? Can it be a MAY?

Well, as a user, I'd like to be informed that my CUA is not showing me
everything I should know. OTOH, [iTIP] says a CUA can ignore ATTACH
properties, so I guess it can be MAY.

> > A limited CS SHOULD try not to lose ATTACHments. One method would be
> > to provide an iMIP+CAP client that stores attachments on any appropriate
> > file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
> > ATTACH properties to reference the appropriate URI. It is advisable
> > that CS which have no limitations, but want to support clients with
> > limited capabilities, do the same conversion, either at time or
> > retrieval time.
> 
>   Is this needed? Can it be a MAY?

OK.


Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 13:30:55 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00471
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 13:30:54 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8CH9ew12607
	for ietf-calendar-bks; Thu, 12 Sep 2002 10:09:40 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CH9ck12603
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 10:09:39 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id B56751552D; Thu, 12 Sep 2002 19:09:38 +0200 (CEST)
Date: Thu, 12 Sep 2002 19:09:38 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
Message-ID: <20020912170938.GH20567@inet.it>
References: <20020911113243.GD91461@inet.it> <3D80B72E.B1B55EEA@oracle.com> <3D80BE9C.125F5FB4@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D80BE9C.125F5FB4@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Thu, Sep 12, 2002 at 10:19:40AM -0600, Doug Royer wrote:
> > 
> >   Should we restrict it to one text/calendar part only? Is there a reason
> > to have more than one part? By specifying only one way, it may make
> > interoperability easier?
> 
> Why would that make it easier?
> 
> 	while (more-text-calendar) {
> 		process-text-calendar
> 	}

While that may be true (as I said, I wouldn't like different commands
in the same transaction), what would be the advantage?

> > > If a CUA or a CS don't support this form, they MUST respond with an
> > > appropriate REQUEST-STATUS.
> > 
> >   We would need to find a new response code for this.
> >   I think we still need to fix the response codes in CAP.
> >   Doug, I believe we decided to do this once CAP is close to
> >   being finalized?
> 
> Yes, however there may not be any need for any error.
> The other endpoint would know this from the MULTIPART capability.

I would agree if the negotiation is sent as piggyback upon opening a
BEEP channel. This would also be nice to have for other things, i.e.
locale etc.

Or we could make the GET-CAPABILITY negotiation mandatory as the
first command (ugly, as it would force the channel to be stateful).
This would be mean we'd need to introduce an error anyway (command
sent before negotiation), so no real advantage.

At worst, it could be 9.0 (command not recognized); but the nice
thing of having a new request status is that it would permit graceful
fallback.

> > >  3.2.1 cid: URI
> > >
> > > A CUA or a CS which doesn't support multipart can't properly handle
> > > properties with a cid: URI value; this affects ATTACH properties and
> > > any property which allows the ALTREP parameter.
> > >
> > > A limited CUA SHOULD inform the user that there is an attachment but
> > > it is not able to access it. It should also provide alternative ways
> > > to attach files to outgoing components. One method would be to store
> > > the file on an appropriate file store and store the URI.
> > 
> >   Is this needed? Can it be a MAY?
> 
> I agree - MAY. And I would also like the CS to have the
> option of making it an inline ATTACH.

OK with me, that's why I said 'one method'.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 14:05:15 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01550
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 14:05:15 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8CHu4F14692
	for ietf-calendar-bks; Thu, 12 Sep 2002 10:56:04 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CHu3k14688
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 10:56:03 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8CHu3dn010830
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 10:56:05 -0700
Message-ID: <3D80D421.D8CEC3C@Royer.com>
Date: Thu, 12 Sep 2002 11:51:29 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Proposal about multipart etc
References: <20020911113243.GD91461@inet.it> <3D80B72E.B1B55EEA@oracle.com> <20020912165534.GG20567@inet.it>
Content-Type: multipart/mixed;
 boundary="------------59349CC8C3C19EEC5388114D"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------59349CC8C3C19EEC5388114D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:

> I agree. Also, if nobody else beats me to it, I think I will prepare
> a proposal in a few days for the response codes every command can
> generate (what can go wrong for each command); from then it should be
> easier to build a final list.

We have tried the before. We need to wait until CAP is ready.
Otherwise they keep changing. I think we can agree
that that a code will exist - its value unspecified for now.

At the same time they need to be coordinated with 244[567].
Currently - they are not.
--------------59349CC8C3C19EEC5388114D
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------59349CC8C3C19EEC5388114D--



From owner-ietf-calendar@mail.imc.org  Thu Sep 12 14:14:20 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01882
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 14:14:20 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CHqai14407
	for ietf-calendar-bks; Thu, 12 Sep 2002 10:52:36 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CHqZk14401
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 10:52:35 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8CHqUdn010802
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 10:52:37 -0700
Message-ID: <3D80D34C.672191C0@Royer.com>
Date: Thu, 12 Sep 2002 11:47:56 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Proposal about multipart etc
References: <20020911113243.GD91461@inet.it> <3D80B72E.B1B55EEA@oracle.com> <3D80BE9C.125F5FB4@Royer.com> <20020912170938.GH20567@inet.it>
Content-Type: multipart/mixed;
 boundary="------------FF86233C8894ED6D0BBD8E29"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------FF86233C8894ED6D0BBD8E29
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrea Campi wrote:
> 
> On Thu, Sep 12, 2002 at 10:19:40AM -0600, Doug Royer wrote:
> > >
> > >   Should we restrict it to one text/calendar part only? Is there a reason
> > > to have more than one part? By specifying only one way, it may make
> > > interoperability easier?
> >
> > Why would that make it easier?
> >
> >       while (more-text-calendar) {
> >               process-text-calendar
> >       }
> 
> While that may be true (as I said, I wouldn't like different commands
> in the same transaction), what would be the advantage?

Not different commands, multiple text/calendar objects in a reply.
Or multiple text/calendar in one command.
All limited to the CAPABILITY of the endpoint.

> > > > If a CUA or a CS don't support this form, they MUST respond with an
> > > > appropriate REQUEST-STATUS.
> > >
> > >   We would need to find a new response code for this.
> > >   I think we still need to fix the response codes in CAP.
> > >   Doug, I believe we decided to do this once CAP is close to
> > >   being finalized?
> >
> > Yes, however there may not be any need for any error.
> > The other endpoint would know this from the MULTIPART capability.
> 
> I would agree if the negotiation is sent as piggyback upon opening a
> BEEP channel. This would also be nice to have for other things, i.e.
> locale etc.

Not part of BEEP, part of CAPABILITY.

> Or we could make the GET-CAPABILITY negotiation mandatory as the
> first command (ugly, as it would force the channel to be stateful).
> This would be mean we'd need to introduce an error anyway (command
> sent before negotiation), so no real advantage.

I have already proposed a MULTIPART capability:

	MULTIPART: related, alternate, mixed, ...

And if empty the endpoint does not support any multipart.
--------------FF86233C8894ED6D0BBD8E29
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------FF86233C8894ED6D0BBD8E29--



From owner-ietf-calendar@mail.imc.org  Thu Sep 12 15:07:23 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04009
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:07:23 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8CJ0sd19412
	for ietf-calendar-bks; Thu, 12 Sep 2002 12:00:54 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CJ0rk19407
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 12:00:53 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id B1E5F1552D; Thu, 12 Sep 2002 21:00:51 +0200 (CEST)
Date: Thu, 12 Sep 2002 21:00:51 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
Message-ID: <20020912190051.GJ20567@inet.it>
References: <20020911113243.GD91461@inet.it> <3D80B72E.B1B55EEA@oracle.com> <3D80BE9C.125F5FB4@Royer.com> <20020912170938.GH20567@inet.it> <3D80D34C.672191C0@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D80D34C.672191C0@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Thu, Sep 12, 2002 at 11:47:56AM -0600, Doug Royer wrote:
> > > Why would that make it easier?
> > >
> > >       while (more-text-calendar) {
> > >               process-text-calendar
> > >       }
> > 
> > While that may be true (as I said, I wouldn't like different commands
> > in the same transaction), what would be the advantage?
> 
> Not different commands, multiple text/calendar objects in a reply.

The text in parenthesis was an explication of why I said "may" - i.e.,
I wouldn't like it for commands, but I agree it's easy for replies.

> Or multiple text/calendar in one command.
> All limited to the CAPABILITY of the endpoint.

You didn't answer my query - what would be the advantage?
Not that I care to fight over this; I said I have no strong opinion
and it would be limited by the CAPABILITY. I just want to undertand.

> > Or we could make the GET-CAPABILITY negotiation mandatory as the
> > first command (ugly, as it would force the channel to be stateful).
> > This would be mean we'd need to introduce an error anyway (command
> > sent before negotiation), so no real advantage.
> 
> I have already proposed a MULTIPART capability:
> 
> 	MULTIPART: related, alternate, mixed, ...
> 
> And if empty the endpoint does not support any multipart.

Then we must mandate that each endpoint must assume the other endpoint
does not support any until they do the GET-CAPABILITY handshaking.

With this provision, I agree and support your proposal.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 15:09:06 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04061
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:09:06 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8CIurp19294
	for ietf-calendar-bks; Thu, 12 Sep 2002 11:56:53 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CIupk19288
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 11:56:52 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 938091552D; Thu, 12 Sep 2002 20:56:48 +0200 (CEST)
Date: Thu, 12 Sep 2002 20:56:48 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
Message-ID: <20020912185648.GI20567@inet.it>
References: <20020911113243.GD91461@inet.it> <3D80B72E.B1B55EEA@oracle.com> <20020912165534.GG20567@inet.it> <3D80D421.D8CEC3C@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D80D421.D8CEC3C@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Thu, Sep 12, 2002 at 11:51:29AM -0600, Doug Royer wrote:
> Andrea Campi wrote:
> 
> > I agree. Also, if nobody else beats me to it, I think I will prepare
> > a proposal in a few days for the response codes every command can
> > generate (what can go wrong for each command); from then it should be
> > easier to build a final list.
> 
> We have tried the before. We need to wait until CAP is ready.
> Otherwise they keep changing. I think we can agree
> that that a code will exist - its value unspecified for now.

OK.

> At the same time they need to be coordinated with 244[567].
> Currently - they are not.

I agree.


Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 15:11:17 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04134
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:11:16 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CIutB19298
	for ietf-calendar-bks; Thu, 12 Sep 2002 11:56:55 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CIurk19290
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 11:56:53 -0700 (PDT)
In-Reply-To: <3D7F893F.2AA1D4EE@Royer.com>
To: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002
Message-ID: <OF6B91BC84.4DF3E31E-ON85256C32.00585697-85256C32.0068056C@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 12 Sep 2002 14:56:36 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/12/2002 02:51:17 PM,
	Serialize complete at 09/12/2002 02:51:17 PM
Content-Type: multipart/alternative; boundary="=_alternative 0068056285256C32_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0068056285256C32_=
Content-Type: text/plain; charset="US-ASCII"

Doug repsonded on 09/11/2002 02:19:43 PM:
> > The draft currently does not reference how to actually 'modify' an
> > existing inlined ATTACHMENT, merely how to identify one to remove (so
> > why is this under 9.5 MODIFY???):
> 
> It would work for inline attachments:
> 
>    WAS:
>       ATTACH ......:old---data
> 
>    NOW:
> 
>       ATTACH ......:new---data

That would work for single inline ATTACHments but not mulitple ones.  I 
have seen no way for the CUA to send back an ATTACHment fragment to 
indicate which was being modified and replaced w/the new ATTACHment 
(either inline or non-inline). 

For the case of a single inline ATTACHment, no partial data would be 
required but I dont think you are suggesting that we limit inline 
ATTACHments to 1 per entity so Im still confused how you do this.

How would the modify work for non-inline ATTACHments?  Still not sure how 
this is ATTACHment matching is supposed to work for non-inline and 
mulitple ATTACHment cases, sorry.

> > > When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
> > > identify the contents of the ATTACHMENT value in the old-values in
> > > order to delete them.  When the CS compares the attachment data it
> > > is compared in its binary form.  The ATTACHMENT value supplied by 
the
> > >  CUA MUST BE valid encoded information.
> > 
> > [Emphasis mine]  There is no talk of actually modifying inline
> > ATTACHments, just how to remove them.  There is also no clear info on
> > what to do to modify or remove non-inlined ATTACHments.  I would
> > expect that to remove them simply specifying a CID / URI could be
> > sufficient but to modify them is a different story.
> 
> It would work for removal and modification of inline attachments.

Again, the CAP text clearly uses the phrase "to delete them".  There is no 
mention of "to modify them".  Perhaps if I better understood how the 
example above were to work I could suggest better phrasing in the cited 
text... 

> Yes - you could modify the URL, or you can modify the inline attachment
> value, but you can not modify the value of a non-inline attachment,
> or the value of a CID or MID body part.

Just want to be 100% certain Im not misinterpreting your phrases:

"modify the value of a non-inline attachment" meaning that its out of 
scope of CAP how a CUA changes the actual contents of the data found at 
the URI http://files.foo.org/~jDoe/CAPAgenda12Sep02.zip ?  (ie: WebDAV, 
FTP, WebSphere, FrontPage, etc. yes?)

"modify the ... value of a CID or MID body part" meaning that the CUA can 
modify the ATTACH:CID:... value but NOT the _contents_ of the CID or MID 
body part? 

I can always point to a different CID, the CUA just cant modify the data 
in part labled w/that CID.  The CID is globally unique and we have not 
contemplated that the CUA could 'rewrite' the body part ala IMAP but 
maybe...  After all, if the CID data is w/in the calendar then its still 
unclear _how_ it gets created/managed/removed (especially removed given 
Johns penchant for referencing body parts in other MIME streams).  If we 
take the KISS approach and disallow referencing CIDs from other streams 
then the issues do get simplified a lot!  (Applying common sense is not 
against the IETF Tao...)

> > However, if the URI is a CID to an entity in the calendar then just
> > what happens to this body part if noone references it?
> 
> Why would that be any different than a long DESCRIPTION value?
> Would you keep that around?

As John so oft points out, the CID _could_ reference an ATTACHment on 
another MIME stream.  If we disallow this for CAP then thats no longer a 
big issue.  If we do not disallow this then you would need to keep a 
deleted entity around because one of its ATTACHments is referenced by 
another entity in the same calendar; removing it when the entity was 
deleted would effectly break the link and lose the ATTACHment in the 
second entity.

In doing an informal check of several power C&S users I have access to I 
found 0, repeat 0, that used the same attachment for multiple meetings (I 
discount my couple of test cases where I did it to test something out a 
long time ago).  I suggest that we say, no "cross stream" CID references 
are allowed in CAP ("Dont cross the streams") and keep moving forward.

> > How is the entity created/modified/removed from the actual store?
> 
> That's up to the implementation. I assumed that you mean
> the value that the CID is pointing to? And I assumed you
> meant that it had arrived as a body part to the original
> message?

I had no assumptions (just some ideas).  I can see a CUA encoding and 
sending the ATTACHment as part of a multipart MIME stream to crate it 
originally.  If the CUA makes local changes, reencodes it and resends it 
the way it was created originally it would have to reuse the original CID 
in order to modify the current copy in the store.  The delete is totally 
unclear from the draft but if we simplify things a bit (see above) then by 
virtue of the fact that the CID is no longer in the MIME stream associated 
w/the calendar entity it would be removed from the store.  However there 
is no text to that effect and its just my opinion as to how it _could_ 
work.  (If the CS chose to keep the CID around after a rewrite then I hope 
you have lots of disk space for those that make lots of changs...)

> > If my UA simply changed ATTACH:cid:<12345@foo.net> to
> > ATTACH:cid:<67890@foo.net> then what becomes of the data at
> > cid:<12345@foo.net> and how does the new data get to
> > cid:<67890@foo.net>??
> 
> If you update the component to the new attach value, then
> that has nothing to do with the fact that cid:<12345@foo.net>
> is still valid or might not be valid.
>
> The only thing you do is inform the CS that the ATTACH value
> is now a different CID. If the CID value is stored in the CS
> (inlined or body part), then the CS will need to know how to
> do its own garbage collection.

So it sounds like you say the CS should remove the data in 
cid:<12345@foo.net>.  If so, we agree once again.  However the CAP draft 
has not text to this effect and it should!

> That's fine. I have noted it in my copy. If anyone has any
> proposals for new text - please post. Otherwise in a week or
> two after this settles down, I'll add/change text.

Thank you.

> Okay. Any object a CS implementation can send, I would think
> it better be able to receive. So my reply may have not
> been dead center, but I think it still applied for both
> directions of data transfer.

Still not making myself (and George?) clear on this.  The cited text:

         The ATTACHMENT value supplied by the CUA MUST BE
         valid encoded information.

is vague and does not read well.  If the intent is to describe encoding 
data and parameters as you've said then perhaps you can beef up that cited 
line to include some text to that effect.  Thats all that should be 
necessary I think.

> If you mean that OBJECT-1 has body part- "bp-1" and OBJECT-2 uses
> a MID of "OBJECT-1/bp-1", that is valid MIME.

I concur.

> So the question becomes, should the CS keep a reference counter?
> I would say it can, but it is not required to do so. The same
> is true with an MUA. An MUA can contain a body part with a MID
> to another body part in another message, it is still valid MIME
> object, and the MID is still valid. It's just that what it points to
> may have been erased. 

Again, I agree.

> I would say not to do reference counting on MIDs and CIDs.

In the interest of KISS I would say good.  I would prefer that we disallow 
cross message/stream references for this reason but I wont start a war 
over it.  Its not outside of our pervue to make such a restriction and 
well worth it to ourselves in the long run (unless someone can think of 
why its not and give reasonable reasons to justify it)...

> > I do agree that only safe way to send the ATTACH is to put it into a
> > same MIME object/stream (see previous postings for why).
> 
> I agree.

And there was much rejoicing...

> Your right, as soon as I sent the email, I remembered how to
> do that and posted it.

Havent seen it yet but Im still just barely treading water in this latest 
flood of messages...

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...


--=_alternative 0068056285256C32_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug repsonded on 09/11/2002 02:19:43 PM:<br>
&gt; &gt; The draft currently does not reference how to actually 'modify'
an<br>
&gt; &gt; existing inlined ATTACHMENT, merely how to identify one to remove
(so<br>
&gt; &gt; why is this under 9.5 MODIFY???):<br>
&gt; <br>
&gt; It would work for inline attachments:<br>
&gt; <br>
&gt; &nbsp; &nbsp;WAS:<br>
&gt; &nbsp; &nbsp; &nbsp; ATTACH ......:old---data<br>
&gt; <br>
&gt; &nbsp; &nbsp;NOW:<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; ATTACH ......:new---data<br>
</tt></font>
<br><font size=2 face="sans-serif">That would work for single inline ATTACHments
but not mulitple ones. &nbsp;I have seen no way for the CUA to send back
an ATTACHment fragment to indicate which was being modified and replaced
w/the new ATTACHment (either inline or non-inline). &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">For the case of a single inline ATTACHment,
no partial data would be required but I dont think you are suggesting that
we limit inline ATTACHments to 1 per entity so Im still confused how you
do this.</font>
<br>
<br><font size=2 face="sans-serif">How would the modify work for non-inline
ATTACHments? &nbsp;Still not sure how this is ATTACHment matching is supposed
to work for non-inline and mulitple ATTACHment cases, sorry.</font>
<br>
<br><font size=2><tt>&gt; &gt; &gt; When it comes to inline ATTACHMENTs,
the CUA only needs to uniquely<br>
&gt; &gt; &gt; identify the contents of the ATTACHMENT value in the old-values
in<br>
&gt; &gt; &gt; order to delete them. &nbsp;When the CS compares the attachment
data it<br>
&gt; &gt; &gt; is compared in its binary form. &nbsp;The ATTACHMENT value
supplied by the<br>
&gt; &gt; &gt; &nbsp;CUA MUST BE valid encoded information.<br>
&gt; &gt; <br>
&gt; &gt; [Emphasis mine] &nbsp;There is no talk of actually modifying
inline<br>
&gt; &gt; ATTACHments, just how to remove them. &nbsp;There is also no
clear info on<br>
&gt; &gt; what to do to modify or remove non-inlined ATTACHments. &nbsp;I
would<br>
&gt; &gt; expect that to remove them simply specifying a CID / URI could
be<br>
&gt; &gt; sufficient but to modify them is a different story.<br>
&gt; <br>
&gt; It would work for removal and modification of inline attachments.<br>
</tt></font>
<br><font size=2 face="sans-serif">Again, the CAP text clearly uses the
phrase &quot;to delete them&quot;. &nbsp;There is no mention of &quot;to
modify them&quot;. &nbsp;Perhaps if I better understood how the example
above were to work I could suggest better phrasing in the cited text...
&nbsp;</font>
<br>
<br><font size=2><tt>&gt; Yes - you could modify the URL, or you can modify
the inline attachment<br>
&gt; value, but you can not modify the value of a non-inline attachment,<br>
&gt; or the value of a CID or MID body part.<br>
</tt></font>
<br><font size=2 face="sans-serif">Just want to be 100% certain Im not
misinterpreting your phrases:</font>
<br>
<br><font size=2 face="sans-serif">&quot;modify the value of a non-inline
attachment&quot; meaning that its out of scope of CAP how a CUA changes
the actual contents of the data found at the URI http://files.foo.org/~jDoe/CAPAgenda12Sep02.zip
? &nbsp;(ie: WebDAV, FTP, WebSphere, FrontPage, etc. yes?)</font>
<br>
<br><font size=2 face="sans-serif">&quot;modify the ... value of a CID
or MID body part&quot; meaning that the CUA can modify the ATTACH:CID:...
value but NOT the _<u>contents</u>_ of the CID or MID body part? &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">I can always point to a different CID,
the CUA just cant modify the data in part labled w/that CID. &nbsp;The
CID is globally unique and we have not contemplated that the CUA could
'rewrite' the body part ala IMAP but maybe... &nbsp;After all, if the CID
data is w/in the calendar then its still unclear _<u>how</u>_ it gets created/managed/removed
(especially removed given Johns penchant for referencing body parts in
other MIME streams). &nbsp;If we take the KISS approach and disallow referencing
CIDs from other streams then the issues do get simplified a lot! &nbsp;(Applying
common sense is not against the IETF Tao...)</font>
<br>
<br><font size=2><tt>&gt; &gt; However, if the URI is a CID to an entity
in the calendar then just<br>
&gt; &gt; what happens to this body part if noone references it?<br>
&gt; <br>
&gt; Why would that be any different than a long DESCRIPTION value?<br>
&gt; Would you keep that around?<br>
</tt></font>
<br><font size=2 face="sans-serif">As John so oft points out, the CID _<u>could</u>_
reference an ATTACHment on another MIME stream. &nbsp;If we disallow this
for CAP then thats no longer a big issue. &nbsp;If we do not disallow this
then you would need to keep a deleted entity around because one of its
ATTACHments is referenced by another entity in the same calendar; removing
it when the entity was deleted would effectly break the link and lose the
ATTACHment in the second entity.</font>
<br>
<br><font size=2 face="sans-serif">In doing an informal check of several
power C&amp;S users I have access to I found 0, repeat 0, that used the
same attachment for multiple meetings (I discount my couple of test cases
where I did it to test something out a long time ago). &nbsp;I suggest
that we say, no &quot;cross stream&quot; CID references are allowed in
CAP (&quot;</font><a><font size=2 color=blue face="sans-serif">Dont cross
the streams</font></a><font size=2 face="sans-serif">&quot;) and keep moving
forward.</font>
<br>
<br><font size=2><tt>&gt; &gt; How is the entity created/modified/removed
from the actual store?<br>
&gt; <br>
&gt; That's up to the implementation. I assumed that you mean<br>
&gt; the value that the CID is pointing to? And I assumed you<br>
&gt; meant that it had arrived as a body part to the original<br>
&gt; message?<br>
</tt></font>
<br><font size=2 face="sans-serif">I had no assumptions (just some ideas).
&nbsp;I can see a CUA encoding and sending the ATTACHment as part of a
multipart MIME stream to crate it originally. &nbsp;If the CUA makes local
changes, reencodes it and resends it the way it was created originally
it would have to reuse the original CID in order to modify the current
copy in the store. &nbsp;The delete is totally unclear from the draft but
if we simplify things a bit (see above) then by virtue of the fact that
the CID is no longer in the MIME stream associated w/the calendar entity
it would be removed from the store. &nbsp;However there is no text to that
effect and its just my opinion as to how it _could_ work. &nbsp;(If the
CS chose to keep the CID around after a rewrite then I hope you have lots
of disk space for those that make lots of changs...)</font>
<br>
<br><font size=2><tt>&gt; &gt; If my UA simply changed ATTACH:cid:&lt;12345@foo.net&gt;
to<br>
&gt; &gt; ATTACH:cid:&lt;67890@foo.net&gt; then what becomes of the data
at<br>
&gt; &gt; cid:&lt;12345@foo.net&gt; and how does the new data get to<br>
&gt; &gt; cid:&lt;67890@foo.net&gt;??<br>
&gt; <br>
&gt; If you update the component to the new attach value, then<br>
&gt; that has nothing to do with the fact that cid:&lt;12345@foo.net&gt;<br>
&gt; is still valid or might not be valid.<br>
&gt;</tt></font>
<br><font size=2><tt>&gt; The only thing you do is inform the CS that the
ATTACH value<br>
&gt; is now a different CID. If the CID value is stored in the CS<br>
&gt; (inlined or body part), then the CS will need to know how to<br>
&gt; do its own garbage collection.<br>
</tt></font>
<br><font size=2 face="sans-serif">So it sounds like you say the CS should
remove the data in cid:&lt;12345@foo.net&gt;. &nbsp;If so, we agree once
again. &nbsp;However the CAP draft has not text to this effect and it should!</font>
<br>
<br><font size=2><tt>&gt; That's fine. I have noted it in my copy. If anyone
has any<br>
&gt; proposals for new text - please post. Otherwise in a week or<br>
&gt; two after this settles down, I'll add/change text.<br>
</tt></font>
<br><font size=2 face="sans-serif">Thank you.</font>
<br>
<br><font size=2><tt>&gt; Okay. Any object a CS implementation can send,
I would think<br>
&gt; it better be able to receive. So my reply may have not<br>
&gt; been dead center, but I think it still applied for both<br>
&gt; directions of data transfer.<br>
</tt></font>
<br><font size=2 face="sans-serif">Still not making myself (and George?)
clear on this. &nbsp;The cited text:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;The
ATTACHMENT value supplied by the CUA MUST BE<br>
 &nbsp; &nbsp; &nbsp; &nbsp; valid encoded information.</font>
<br>
<br><font size=2 face="sans-serif">is vague and does not read well. &nbsp;If
the intent is to describe encoding data and parameters as you've said then
perhaps you can beef up that cited line to include some text to that effect.
&nbsp;Thats all that should be necessary I think.</font>
<br>
<br><font size=2><tt>&gt; If you mean that OBJECT-1 has body part- &quot;bp-1&quot;
and OBJECT-2 uses<br>
&gt; a MID of &quot;OBJECT-1/bp-1&quot;, that is valid MIME.<br>
</tt></font>
<br><font size=2 face="sans-serif">I concur.</font>
<br>
<br><font size=2><tt>&gt; So the question becomes, should the CS keep a
reference counter?<br>
&gt; I would say it can, but it is not required to do so. The same<br>
&gt; is true with an MUA. An MUA can contain a body part with a MID<br>
&gt; to another body part in another message, it is still valid MIME<br>
&gt; object, and the MID is still valid. It's just that what it points
to<br>
&gt; may have been erased. </tt></font>
<br>
<br><font size=2 face="sans-serif">Again, I agree.</font>
<br><font size=2 face="sans-serif"><br>
</font><font size=2><tt>&gt; I would say not to do reference counting on
MIDs and CIDs.<br>
</tt></font>
<br><font size=2 face="sans-serif">In the interest of KISS I would say
good. &nbsp;I would prefer that we disallow cross message/stream references
for this reason but I wont start a war over it. &nbsp;Its not outside of
our pervue to make such a restriction and well worth it to ourselves in
the long run (unless someone can think of why its not and give reasonable
reasons to justify it)...</font>
<br>
<br><font size=2><tt>&gt; &gt; I do agree that only safe way to send the
ATTACH is to put it into a<br>
&gt; &gt; same MIME object/stream (see previous postings for why).<br>
&gt; <br>
&gt; I agree.<br>
</tt></font>
<br><font size=2 face="sans-serif">And there was much rejoicing...</font>
<br>
<br><font size=2><tt>&gt; Your right, as soon as I sent the email, I remembered
how to<br>
&gt; do that and posted it.</tt></font>
<br>
<br><font size=2 face="sans-serif">Havent seen it yet but Im still just
barely treading water in this latest flood of messages...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
<br>
--=_alternative 0068056285256C32_=--


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 15:43:43 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05250
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:43:42 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8CJQj720396
	for ietf-calendar-bks; Thu, 12 Sep 2002 12:26:45 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CJQhk20390
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 12:26:43 -0700 (PDT)
In-Reply-To: <3D80A6F7.A8AD7DEB@oracle.com>
To: George Babics <george.babics@oracle.com>
Cc: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002
Message-ID: <OFC6113F39.CFF3DAD9-ON85256C32.006A9FB6-85256C32.006AC57C@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 12 Sep 2002 15:26:38 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/12/2002 03:21:07 PM,
	Serialize complete at 09/12/2002 03:21:07 PM
Content-Type: multipart/alternative; boundary="=_alternative 006AC57685256C32_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 006AC57685256C32_=
Content-Type: text/plain; charset="US-ASCII"

George asked on 09/12/2002 10:38:47 AM:
>   Should we have text in the CAP draft recommending how attachments 
should be
> handled?

Clearly we should given the uncertainly that some of us are having and to 
avoid mass confusion and interop nightmares when we start to actually test 
it in the real world.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 006AC57685256C32_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>George asked on 09/12/2002 10:38:47 AM:<br>
&gt; &nbsp; Should we have text in the CAP draft recommending how attachments
should be<br>
&gt; handled?<br>
</tt></font>
<br><font size=2 face="sans-serif">Clearly we should given the uncertainly
that some of us are having and to avoid mass confusion and interop nightmares
when we start to actually test it in the real world.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 006AC57685256C32_=--


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 16:21:28 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06332
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 16:21:28 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CKAZr21750
	for ietf-calendar-bks; Thu, 12 Sep 2002 13:10:35 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CKAYk21744
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 13:10:34 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8CKAOdn011793
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 13:10:36 -0700
Message-ID: <3D80F39D.FCA860E0@Royer.com>
Date: Thu, 12 Sep 2002 14:05:49 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <OF6B91BC84.4DF3E31E-ON85256C32.00585697-85256C32.0068056C@iris.com>
Content-Type: multipart/mixed;
 boundary="------------DA4EC985A0E7DFB400209BEE"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------DA4EC985A0E7DFB400209BEE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug repsonded on 09/11/2002 02:19:43 PM:
> > > The draft currently does not reference how to actually 'modify' an
> > > existing inlined ATTACHMENT, merely how to identify one to remove
> (so
> > > why is this under 9.5 MODIFY???):
> >
> > It would work for inline attachments:
> >
> >    WAS:
> >       ATTACH ......:old---data
> >
> >    NOW:
> >
> >       ATTACH ......:new---data
> 
> That would work for single inline ATTACHments but not mulitple ones.
> I have seen no way for the CUA to send back an ATTACHment fragment to
> indicate which was being modified and replaced w/the new ATTACHment
> (either inline or non-inline).

In CAP:

   When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
   identify the contents of the ATTACHMENT value in the old-values in
   order to delete them.  When the CS compares the attachment data it is
   compared in its binary form.  The ATTACHMENT value supplied by the
   CUA MUST BE valid encoded information.

We should change 'to delete them' to 'to delete or modify them' 
Last sentence is going to be deleted.

Would that solve the issue?
--------------DA4EC985A0E7DFB400209BEE
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------DA4EC985A0E7DFB400209BEE--



From owner-ietf-calendar@mail.imc.org  Thu Sep 12 17:23:43 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08423
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 17:23:42 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CLCvk25157
	for ietf-calendar-bks; Thu, 12 Sep 2002 14:12:57 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CLCtk25152
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 14:12:56 -0700 (PDT)
In-Reply-To: <3D80B72E.B1B55EEA@oracle.com>
To: George Babics <george.babics@oracle.com>
Cc: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002
Message-ID: <OFEEFDE076.4C30AB6D-ON85256C32.00723D7B-85256C32.00747EA4@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 12 Sep 2002 17:12:50 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/12/2002 05:07:19 PM,
	Serialize complete at 09/12/2002 05:07:19 PM
Content-Type: multipart/alternative; boundary="=_alternative 00747E9885256C32_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 00747E9885256C32_=
Content-Type: text/plain; charset="US-ASCII"

George noted on 09/12/2002 11:47:58 AM:
> > A limited CUA SHOULD inform the user that there is an attachment but
> > it is not able to access it. It should also provide alternative ways
> > to attach files to outgoing components. One method would be to store
> > the file on an appropriate file store and store the URI.
> 
>   Is this needed? Can it be a MAY?

Since this involves apparent loss of data (or at least poor fidelity) from 
the CUs perspective Id say that SHOULD is probably better have here. 

Is it better that a CUA should tell the CU that there is data that it 
cannot access or that that a CUA may or may not notify the CU that there 
is data that cannot be presented to them?  I think the CU should be told 
since it directly involves how they perceive the fidelity of the data 
being presented ("The description says 'Please review the attached proofs 
before the meeting' but I dont see any attached docs.  Did they not get 
sent?")

> > A limited CS SHOULD try not to lose ATTACHments. One method would be
> > to provide an iMIP+CAP client that stores attachments on any 
appropriate
> > file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
> > ATTACH properties to reference the appropriate URI. It is advisable
> > that CS which have no limitations, but want to support clients with
> > limited capabilities, do the same conversion, either at time or
> > retrieval time.
> 
>   Is this needed? Can it be a MAY?

I think it is needed and that SHOULD is the proper choice (at least for 
the not losing ATTAChments bits).  See above for why.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...


--=_alternative 00747E9885256C32_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>George noted on 09/12/2002 11:47:58 AM:<br>
&gt; &gt; A limited CUA SHOULD inform the user that there is an attachment
but<br>
&gt; &gt; it is not able to access it. It should also provide alternative
ways<br>
&gt; &gt; to attach files to outgoing components. One method would be to
store<br>
&gt; &gt; the file on an appropriate file store and store the URI.<br>
&gt; <br>
&gt; &nbsp; Is this needed? Can it be a MAY?<br>
</tt></font>
<br><font size=2 face="sans-serif">Since this involves apparent loss of
data (or at least poor fidelity) from the CUs perspective Id say that SHOULD
is probably better have here. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Is it better that a CUA should tell
the CU that there is data that it cannot access or that that a CUA may
or may not notify the CU that there is data that cannot be presented to
them? &nbsp;I think the CU should be told since it directly involves how
they perceive the fidelity of the data being presented (&quot;The description
says 'Please review the attached proofs before the meeting' but I dont
see any attached docs. &nbsp;Did they not get sent?&quot;)</font>
<br>
<br><font size=2><tt>&gt; &gt; A limited CS SHOULD try not to lose ATTACHments.
One method would be<br>
&gt; &gt; to provide an iMIP+CAP client that stores attachments on any
appropriate<br>
&gt; &gt; file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite<br>
&gt; &gt; ATTACH properties to reference the appropriate URI. It is advisable<br>
&gt; &gt; that CS which have no limitations, but want to support clients
with<br>
&gt; &gt; limited capabilities, do the same conversion, either at time
or<br>
&gt; &gt; retrieval time.<br>
&gt; <br>
&gt; &nbsp; Is this needed? Can it be a MAY?<br>
</tt></font>
<br><font size=2 face="sans-serif">I think it is needed and that SHOULD
is the proper choice (at least for the not losing ATTAChments bits). &nbsp;See
above for why.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
<br>
--=_alternative 00747E9885256C32_=--


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 17:27:32 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08532
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 17:27:32 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CLMuM25475
	for ietf-calendar-bks; Thu, 12 Sep 2002 14:22:56 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CLMtk25471
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 14:22:55 -0700 (PDT)
In-Reply-To: <3D80BE9C.125F5FB4@Royer.com>
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002
Message-ID: <OF13BF44E3.532D1CA5-ON85256C32.00749EFE-85256C32.00756931@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 12 Sep 2002 17:22:51 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/12/2002 05:17:18 PM,
	Serialize complete at 09/12/2002 05:17:18 PM
Content-Type: multipart/alternative; boundary="=_alternative 0075692D85256C32_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0075692D85256C32_=
Content-Type: text/plain; charset="US-ASCII"

Doug replied on 09/12/2002 12:19:40 PM:
>                And I would also like the CS to have the
> option of making it an inline ATTACH.

I hope you dont like the idea of the CS inlining the 5M ZIP file.  The 
intent of inline was for _small_ binaries.  If my iCalendar parser has to 
parse and save off the inlined data just to get to the next property it 
will but thats just delaying my processing and rendering of it for the CU. 
 

I have no objections to inlining small binaries (we can nit pick over what 
"small" means later) but I do not like the idea of the CS inlining a 
possibly very large blob of data that delays my processing and rendering. 
I can always tell the CU "Sorry, you cannot view that MPEG yet as its not 
fully downloaded" if its in a separate body part that follows the 
iCalendar body part but I cannot render the iCalendar fully until the 
monster ATTACHment is 'uninlined' so I can get to the properties that come 
after it in the MIME stream (they just get to see the hourglass cursor 
while I stream it down from the CS and cache it off).

Why do you want the CS to inline (I presume) all ATTACHments instead of 
allowing them to be in other MIME body parts??  (I dont see a benefit/need 
here unless you have a backend engine in mind that cannot handle the 
concept of attachments otherwise...)

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...


--=_alternative 0075692D85256C32_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug replied on 09/12/2002 12:19:40 PM:<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;And I would
also like the CS to have the<br>
&gt; option of making it an inline ATTACH.</tt></font>
<br>
<br><font size=2 face="sans-serif">I hope you dont like the idea of the
CS inlining the 5M ZIP file. &nbsp;The intent of inline was for _small_
binaries. &nbsp;If my iCalendar parser has to parse and save off the inlined
data just to get to the next property it will but thats just delaying my
processing and rendering of it for the CU. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">I have no objections to inlining small
binaries (we can nit pick over what &quot;small&quot; means later) but
I do not like the idea of the CS inlining a possibly very large blob of
data that delays my processing and rendering. &nbsp;I can always tell the
CU &quot;Sorry, you cannot view that MPEG yet as its not fully downloaded&quot;
if its in a separate body part that follows the iCalendar body part but
I cannot render the iCalendar fully until the monster ATTACHment is 'uninlined'
so I can get to the properties that come after it in the MIME stream (they
just get to see the hourglass cursor while I stream it down from the CS
and cache it off).</font>
<br>
<br><font size=2 face="sans-serif">Why do you want the CS to inline (I
presume) all ATTACHments instead of allowing them to be in other MIME body
parts?? &nbsp;(I dont see a benefit/need here unless you have a backend
engine in mind that cannot handle the concept of attachments otherwise...)</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
<br>
--=_alternative 0075692D85256C32_=--


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 17:38:26 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08771
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 17:38:26 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CLY2725752
	for ietf-calendar-bks; Thu, 12 Sep 2002 14:34:02 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CLY0k25748
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 14:34:00 -0700 (PDT)
In-Reply-To: <20020912165534.GG20567@inet.it>
To: Andrea Campi <a.campi@inet.it>
Cc: George Babics <george.babics@oracle.com>, ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002
Message-ID: <OF2C02A94E.6C57B665-ON85256C32.00762D5F-85256C32.00766C6A@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 12 Sep 2002 17:33:54 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/12/2002 05:28:24 PM,
	Serialize complete at 09/12/2002 05:28:24 PM
Content-Type: multipart/alternative; boundary="=_alternative 00766C6585256C32_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 00766C6585256C32_=
Content-Type: text/plain; charset="US-ASCII"

Andrea replied on 09/12/2002 12:55:34 PM:
> > > A limited CUA SHOULD inform the user that there is an attachment but
> > > it is not able to access it. It should also provide alternative ways
> > > to attach files to outgoing components. One method would be to store
> > > the file on an appropriate file store and store the URI.
> > 
> >   Is this needed? Can it be a MAY?
> 
> Well, as a user, I'd like to be informed that my CUA is not showing me
> everything I should know. OTOH, [iTIP] says a CUA can ignore ATTACH
> properties, so I guess it can be MAY.

Not so fast.  There is definite distinction between your "not able to 
access it" and "ignoring the ATTACHment". 

The former means the CUA tried to get it but could not.  The latter means 
that the CUA didnt even try. 

In the former case I, as a CU, would definitely want to know so I think 
SHOULD is in order for that situation.  For the case where the CUA does 
not try then Im flexible...

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 00766C6585256C32_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Andrea replied on 09/12/2002 12:55:34 PM:<br>
&gt; &gt; &gt; A limited CUA SHOULD inform the user that there is an attachment
but<br>
&gt; &gt; &gt; it is not able to access it. It should also provide alternative
ways<br>
&gt; &gt; &gt; to attach files to outgoing components. One method would
be to store<br>
&gt; &gt; &gt; the file on an appropriate file store and store the URI.<br>
&gt; &gt; <br>
&gt; &gt; &nbsp; Is this needed? Can it be a MAY?<br>
&gt; <br>
&gt; Well, as a user, I'd like to be informed that my CUA is not showing
me<br>
&gt; everything I should know. OTOH, [iTIP] says a CUA can ignore ATTACH<br>
&gt; properties, so I guess it can be MAY.<br>
</tt></font>
<br><font size=2 face="sans-serif">Not so fast. &nbsp;There is definite
distinction between your &quot;not able to access it&quot; and &quot;ignoring
the ATTACHment&quot;. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">The former means the CUA tried to get
it but could not. &nbsp;The latter means that the CUA didnt even try. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">In the former case I, as a CU, would
definitely want to know so I think SHOULD is in order for that situation.
&nbsp;For the case where the CUA does not try then Im flexible...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 00766C6585256C32_=--


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 17:41:41 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08916
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 17:41:40 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CLUTg25683
	for ietf-calendar-bks; Thu, 12 Sep 2002 14:30:29 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CLUSk25679
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 14:30:28 -0700 (PDT)
In-Reply-To: <3D80BA87.6CBE459B@Royer.com>
To: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002
Message-ID: <OF3898A764.D90F2B86-ON85256C32.0075987A-85256C32.00761A6C@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 12 Sep 2002 17:30:24 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/12/2002 05:24:51 PM,
	Serialize complete at 09/12/2002 05:24:51 PM
Content-Type: multipart/alternative; boundary="=_alternative 00761A6885256C32_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 00761A6885256C32_=
Content-Type: text/plain; charset="US-ASCII"

Doug wrote on 09/12/2002 12:02:15 PM:
> Some are going to prefer inline others CIDs. For small attachments
> inline is fine, for huge attachments I would use a separate body parts.

Perhaps I just misinterpreted you in the other thread (about inlining 
ATTACHments).  I concur w/you on this for large one!

> If the value is a MID, I would expect one or two body parts - depending
> if the CS has the contents of the MID or not. This is no different
> than e-mail. 

Except that the mail server does not automagically include a referenced 
MIDs contents in another message. 

Im not sure you can copy the MIDs contents into another message's body 
part (effectively making it a CID now) since there is only 1 MID per 
stream and the included data is no longer referenced by a MID (its not a 
message now, its a body part of another message).

>                Just because a MIME object contains a CID or MID (or
> any other URI), does not mean they exist, it means that at once they
> should have existed at one time.

Correct.

> If it is an inline, I would expect one body part - text/calendar
> with the embedded inline ATTACH value.

(We can revisit this when we factor in ALTREPs later...)

> Ether way, if you fetch an ATTACH value, you are going to
> get the contents inline or in another body part (if in the CS).

Yep.  What he said...

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 00761A6885256C32_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug wrote on 09/12/2002 12:02:15 PM:<br>
&gt; Some are going to prefer inline others CIDs. For small attachments<br>
&gt; inline is fine, for huge attachments I would use a separate body parts.<br>
</tt></font>
<br><font size=2 face="sans-serif">Perhaps I just misinterpreted you in
the other thread (about inlining ATTACHments). &nbsp;I concur w/you on
this for large one!</font>
<br>
<br><font size=2><tt>&gt; If the value is a MID, I would expect one or
two body parts - depending<br>
&gt; if the CS has the contents of the MID or not. This is no different<br>
&gt; than e-mail. </tt></font>
<br>
<br><font size=2 face="sans-serif">Except that the mail server does not
automagically include a referenced MIDs contents in another message. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Im not sure you can copy the MIDs contents
into another message's body part (effectively making it a CID now) since
there is only 1 MID per stream and the included data is no longer referenced
by a MID (its not a message now, its a body part of another message).</font>
<br>
<br><font size=2><tt>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;Just because a MIME object contains a CID or MID (or<br>
&gt; any other URI), does not mean they exist, it means that at once they<br>
&gt; should have existed at one time.<br>
</tt></font>
<br><font size=2 face="sans-serif">Correct.</font>
<br>
<br><font size=2><tt>&gt; If it is an inline, I would expect one body part
- text/calendar<br>
&gt; with the embedded inline ATTACH value.<br>
</tt></font>
<br><font size=2 face="sans-serif">(We can revisit this when we factor
in ALTREPs later...)</font>
<br>
<br><font size=2><tt>&gt; Ether way, if you fetch an ATTACH value, you
are going to<br>
&gt; get the contents inline or in another body part (if in the CS).<br>
</tt></font>
<br><font size=2 face="sans-serif">Yep. &nbsp;What he said...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 00761A6885256C32_=--


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 18:01:37 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09484
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 18:01:37 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8CLtFt26350
	for ietf-calendar-bks; Thu, 12 Sep 2002 14:55:15 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CLtEk26343
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 14:55:14 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8CLtEdn012545
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 14:55:16 -0700
Message-ID: <3D810C2E.773158BB@Royer.com>
Date: Thu, 12 Sep 2002 15:50:38 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Proposal about multipart etc
References: <OF13BF44E3.532D1CA5-ON85256C32.00749EFE-85256C32.00756931@iris.com>
Content-Type: multipart/mixed;
 boundary="------------E395CF2DA16A3141C2556F51"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------E395CF2DA16A3141C2556F51
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug replied on 09/12/2002 12:19:40 PM:
> >                And I would also like the CS to have the
> > option of making it an inline ATTACH.
> 
> I hope you dont like the idea of the CS inlining the 5M ZIP file.  The
> intent of inline was for _small_ binaries.  If my iCalendar parser has
> to parse and save off the inlined data just to get to the next
> property it will but thats just delaying my processing and rendering
> of it for the CU.

I agree, but I like loosing data much less.
(And this also applies to a CUA that wishes to send to a CS that
 does not support multipart).

> I have no objections to inlining small binaries (we can nit pick over
> what "small" means later) but I do not like the idea of the CS
> inlining a possibly very large blob of data that delays my processing
> and rendering.  I can always tell the CU "Sorry, you cannot view that
> MPEG yet as its not fully downloaded" if its in a separate body part
> that follows the iCalendar body part but I cannot render the iCalendar
> fully until the monster ATTACHment is 'uninlined' so I can get to the
> properties that come after it in the MIME stream (they just get to see
> the hourglass cursor while I stream it down from the CS and cache it
> off).

If the endpoint does not want large iCalendar objects, it is
free to set its size CAPABILITY to an acceptable limit. However
if it is set to unlimited size, then the endpoint is saying that
it *is* acceptable.

> Why do you want the CS to inline (I presume) all ATTACHments instead
> of allowing them to be in other MIME body parts??  (I dont see a
> benefit/need here unless you have a backend engine in mind that cannot
> handle the concept of attachments otherwise...)

I think you got off of the path here, which was: *Only* when the
other endpoint can not do multipart. If the other endpoint can
do multipart, then multipart IS acceptable and no conversion
to inline is needed.
--------------E395CF2DA16A3141C2556F51
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------E395CF2DA16A3141C2556F51--



From owner-ietf-calendar@mail.imc.org  Thu Sep 12 18:09:51 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09675
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 18:09:50 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CLvTt26570
	for ietf-calendar-bks; Thu, 12 Sep 2002 14:57:29 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CLvSk26564
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 14:57:28 -0700 (PDT)
In-Reply-To: <3D80C3DD.B007BB0B@Royer.com>
To: Doug Royer <Doug@royer.com>
Cc: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002
Message-ID: <OF666BD14B.6BA36727-ON85256C32.00768CB1-85256C32.00772E51@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Thu, 12 Sep 2002 17:42:11 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at
 09/12/2002 05:51:51 PM,
	Serialize complete at 09/12/2002 05:51:51 PM
Content-Type: multipart/alternative; boundary="=_alternative 00772E4D85256C32_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 00772E4D85256C32_=
Content-Type: text/plain; charset="US-ASCII"

Doug posited on 09/12/2002 12:42:05 PM:
> I would think that if one endpoint does not support multipart,
> then the other endpoint should convert all body part attachments
> to inline - and not loose any data and transport them in one 
> text/calendar object. We have size capabilities to limit
> the size of objects. They will be storable or not.

Hmm, so if my CS does not grok multipart and I want to save my ATTACHment 
I have to inline it but if that then exceedes the size limit (because I 
have a big DESCRIPTION, lots of ATTENDEEs, etc) then Im hosed?  Or are 
there other alternatives?

> I agree for ALTREP in a body part. The CUA must decide not
> to store any of it, or break it up into what the CS can store
> and inform the CU.

Just how does the CUA 'break it up' for the CS??  We dont have a way to 
inline ALTREPs, just ATTACHments...

> There is never any reason to loose attachments, they
> can be converted to INLINE by the other endpoint. And
> if they are rejected by the endpoint because of size or VCAR,
> then they can not be trasported between those endpoints anyway.

So a multipart savy CS may not be able to send a large ATTACHment to a 
multipart ignorant CUA because if it was inlined it would be too big for 
the CUA (I didnt see any text on size limits from the CUAs perspective, 
just the CS's)?..

> And for ALTREP, if the CS can not store the body part, then
> it is the CUAs responsibility to store the data or reject
> the iCalendar object. 

Just where is the CUA going to store ALTREPs if the CS does not accept 
them??  "The CS you are using does not accept multipart data so do you 
want me to use an external storage site and put the richer alternate 
content there?" prompting??

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...


--=_alternative 00772E4D85256C32_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug posited on 09/12/2002 12:42:05 PM:<br>
&gt; I would think that if one endpoint does not support multipart,<br>
&gt; then the other endpoint should convert all body part attachments<br>
&gt; to inline - and not loose any data and transport them in one <br>
&gt; text/calendar object. We have size capabilities to limit<br>
&gt; the size of objects. They will be storable or not.<br>
</tt></font>
<br><font size=2 face="sans-serif">Hmm, so if my CS does not grok multipart
and I want to save my ATTACHment I have to inline it but if that then exceedes
the size limit (because I have a big DESCRIPTION, lots of ATTENDEEs, etc)
then Im hosed? &nbsp;Or are there other alternatives?</font>
<br>
<br><font size=2><tt>&gt; I agree for ALTREP in a body part. The CUA must
decide not<br>
&gt; to store any of it, or break it up into what the CS can store<br>
&gt; and inform the CU.<br>
</tt></font>
<br><font size=2 face="sans-serif">Just how does the CUA 'break it up'
for the CS?? &nbsp;We dont have a way to inline ALTREPs, just ATTACHments...</font>
<br>
<br><font size=2><tt>&gt; There is never any reason to loose attachments,
they<br>
&gt; can be converted to INLINE by the other endpoint. And<br>
&gt; if they are rejected by the endpoint because of size or VCAR,<br>
&gt; then they can not be trasported between those endpoints anyway.<br>
</tt></font>
<br><font size=2 face="sans-serif">So a multipart savy CS may not be able
to send a large ATTACHment to a multipart ignorant CUA because if it was
inlined it would be too big for the CUA (I didnt see any text on size limits
from the CUAs perspective, just the CS's)?..</font>
<br>
<br><font size=2><tt>&gt; And for ALTREP, if the CS can not store the body
part, then<br>
&gt; it is the CUAs responsibility to store the data or reject<br>
&gt; the iCalendar object. </tt></font>
<br>
<br><font size=2 face="sans-serif">Just where is the CUA going to store
ALTREPs if the CS does not accept them?? &nbsp;&quot;The CS you are using
does not accept multipart data so do you want me to use an external storage
site and put the richer alternate content there?&quot; prompting??</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
<br>
--=_alternative 00772E4D85256C32_=--


From owner-ietf-calendar@mail.imc.org  Thu Sep 12 18:11:30 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09726
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 18:11:29 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CM2iU26981
	for ietf-calendar-bks; Thu, 12 Sep 2002 15:02:44 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CM2hk26976
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 15:02:43 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8CM2gdn012588
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 15:02:46 -0700
Message-ID: <3D810DEE.7948EB97@Royer.com>
Date: Thu, 12 Sep 2002 15:58:06 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Proposal about multipart etc
References: <OF666BD14B.6BA36727-ON85256C32.00768CB1-85256C32.00772E51@iris.com>
Content-Type: multipart/mixed;
 boundary="------------DE7794BF9EE6562D8098028A"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------DE7794BF9EE6562D8098028A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug posited on 09/12/2002 12:42:05 PM:
> > I would think that if one endpoint does not support multipart,
> > then the other endpoint should convert all body part attachments
> > to inline - and not loose any data and transport them in one
> > text/calendar object. We have size capabilities to limit
> > the size of objects. They will be storable or not.
> 
> Hmm, so if my CS does not grok multipart and I want to save my
> ATTACHment I have to inline it but if that then exceedes the size
> limit (because I have a big DESCRIPTION, lots of ATTENDEEs, etc) then
> Im hosed?

If the endpoint says that the data is too big - your hosed.

> > I agree for ALTREP in a body part. The CUA must decide not
> > to store any of it, or break it up into what the CS can store
> > and inform the CU.
> 
> Just how does the CUA 'break it up' for the CS??  We dont have a way
> to inline ALTREPs, just ATTACHments...

True - I mean - the CUA does it - out of scope for CAP.
The CUA can store the ALTREP or not, but not with CAP.
(I think that a CS that could not handle multipart is busted,
 but some on this list want that, so it is lost, or the CUA
 stores it without CAP).

I do not know of any alternatives.

> > There is never any reason to loose attachments, they
> > can be converted to INLINE by the other endpoint. And
> > if they are rejected by the endpoint because of size or VCAR,
> > then they can not be trasported between those endpoints anyway.
> 
> So a multipart savy CS may not be able to send a large ATTACHment to a
> multipart ignorant CUA because if it was inlined it would be too big
> for the CUA (I didnt see any text on size limits from the CUAs
> perspective, just the CS's)?..

The CAPABILITY is sent both directions. Which includes size.
A CUA MAY support CAPABILITY, if not, the the CUA is declaring
the defaults - unlimited sizes.

> > And for ALTREP, if the CS can not store the body part, then
> > it is the CUAs responsibility to store the data or reject
> > the iCalendar object.
> 
> Just where is the CUA going to store ALTREPs if the CS does not accept
> them??

If a CS can not do it  - then a CS can not do it.

>  "The CS you are using does not accept multipart data so do you
> want me to use an external storage site and put the richer alternate
> content there?" prompting??

I am saying that some on this list want support for multipart
to be a MAY, that means we have to say - sorry - the CUAs problem.
Do you have an alternate?

Keep in mind that not all ALTREPs are multipart/alternate or CIDs.
The multipart/alternate would be the only ones effected - correct?
(Or I guess they could be multipart/related).
--------------DE7794BF9EE6562D8098028A
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------DE7794BF9EE6562D8098028A--



From owner-ietf-calendar@mail.imc.org  Thu Sep 12 18:15:19 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09813
	for <calsch-archive@lists.ietf.org>; Thu, 12 Sep 2002 18:15:18 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8CM7gm27567
	for ietf-calendar-bks; Thu, 12 Sep 2002 15:07:42 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CM7ek27562
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 15:07:40 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8CM7fdn012630
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Thu, 12 Sep 2002 15:07:43 -0700
Message-ID: <3D810F19.96C570B4@Royer.com>
Date: Thu, 12 Sep 2002 16:03:05 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: [Fwd: How To Handle Attachments]
References: <OF3898A764.D90F2B86-ON85256C32.0075987A-85256C32.00761A6C@iris.com>
Content-Type: multipart/mixed;
 boundary="------------036263D471C107F3732C87BB"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------036263D471C107F3732C87BB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce_Kahn@notesdev.ibm.com wrote:

> > If the value is a MID, I would expect one or two body parts -
> > depending if the CS has the contents of the MID or not. This is no
> >  different than e-mail.
> 
> Except that the mail server does not automagically include a
> referenced MIDs contents in another message.

Okay - why do I care? :-)

A MUA+CUA could have done that via iMIP.

> Im not sure you can copy the MIDs contents into another message's body
> part (effectively making it a CID now) since there is only 1 MID per
> stream and the included data is no longer referenced by a MID (its not
> a message now, its a body part of another message).

You don't copy it, but you can reference it (you would get one
body part containing a URI to a MID). A MID is a valid
URI for ATTACH and ALTREP.

And as a MID is a superset of a CID, it can point to other
multipart/related body parts in the same MIME object or different
MIME objects. So you can get one or two body parts with a MID.
--------------036263D471C107F3732C87BB
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------036263D471C107F3732C87BB--



From owner-ietf-calendar@mail.imc.org  Fri Sep 13 11:18:21 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08747
	for <calsch-archive@lists.ietf.org>; Fri, 13 Sep 2002 11:18:20 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8DEq5824295
	for ietf-calendar-bks; Fri, 13 Sep 2002 07:52:05 -0700 (PDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DEq4k24289
	for <ietf-calendar@imc.org>; Fri, 13 Sep 2002 07:52:04 -0700 (PDT)
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8DEq0712117
	for <ietf-calendar@imc.org>; Fri, 13 Sep 2002 07:52:00 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8DEq0p12110
	for <ietf-calendar@imc.org>; Fri, 13 Sep 2002 07:52:00 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8DEpxv24720
	for <ietf-calendar@imc.org>; Fri, 13 Sep 2002 08:51:59 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8DEpvf24689
	for <ietf-calendar@imc.org>; Fri, 13 Sep 2002 08:51:57 -0600 (MDT)
Message-ID: <3D81FB8C.8CC5A42@oracle.com>
Date: Fri, 13 Sep 2002 10:51:56 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <OF666BD14B.6BA36727-ON85256C32.00768CB1-85256C32.00772E51@iris.com> <3D810DEE.7948EB97@Royer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Doug Royer wrote:
> 
> Bruce_Kahn@notesdev.ibm.com wrote:
> >
> > Doug posited on 09/12/2002 12:42:05 PM:
> > > I would think that if one endpoint does not support multipart,
> > > then the other endpoint should convert all body part attachments
> > > to inline - and not loose any data and transport them in one
> > > text/calendar object. We have size capabilities to limit
> > > the size of objects. They will be storable or not.
> >
> > Hmm, so if my CS does not grok multipart and I want to save my
> > ATTACHment I have to inline it but if that then exceedes the size
> > limit (because I have a big DESCRIPTION, lots of ATTENDEEs, etc) then
> > Im hosed?
> 
> If the endpoint says that the data is too big - your hosed.

  Shouldn't the CUA be able to detect that an event has a large
inline attachment, and decide not to get the attachment but get
the rest of the event? Or if the attachment is too big for
the CUA, the attachment is not returned? The CUA can display a
message to the CU that the attachment was too big to download.
Should the CU not be able to see the event because the attachment
is too big?

  An inline attachment can easily get very big, especially, if the
CUA does not support multipart. However, how often can a DESCRIPTION,
SUMMARY, number of ATTENDEES, etc., be bigger than the maximum? What
would a typical maximum be? 1K, 10K, 100K?

> 
> > > I agree for ALTREP in a body part. The CUA must decide not
> > > to store any of it, or break it up into what the CS can store
> > > and inform the CU.
> >
> > Just how does the CUA 'break it up' for the CS??  We dont have a way
> > to inline ALTREPs, just ATTACHments...
> 
> True - I mean - the CUA does it - out of scope for CAP.
> The CUA can store the ALTREP or not, but not with CAP.
> (I think that a CS that could not handle multipart is busted,
>  but some on this list want that, so it is lost, or the CUA
>  stores it without CAP).
> 
> I do not know of any alternatives.
> 
> > > There is never any reason to loose attachments, they
> > > can be converted to INLINE by the other endpoint. And
> > > if they are rejected by the endpoint because of size or VCAR,
> > > then they can not be trasported between those endpoints anyway.
> >
> > So a multipart savy CS may not be able to send a large ATTACHment to a
> > multipart ignorant CUA because if it was inlined it would be too big
> > for the CUA (I didnt see any text on size limits from the CUAs
> > perspective, just the CS's)?..
> 
> The CAPABILITY is sent both directions. Which includes size.
> A CUA MAY support CAPABILITY, if not, the the CUA is declaring
> the defaults - unlimited sizes.
> 
> > > And for ALTREP, if the CS can not store the body part, then
> > > it is the CUAs responsibility to store the data or reject
> > > the iCalendar object.
> >
> > Just where is the CUA going to store ALTREPs if the CS does not accept
> > them??
> 
> If a CS can not do it  - then a CS can not do it.
> 
> >  "The CS you are using does not accept multipart data so do you
> > want me to use an external storage site and put the richer alternate
> > content there?" prompting??
> 
> I am saying that some on this list want support for multipart
> to be a MAY, that means we have to say - sorry - the CUAs problem.
> Do you have an alternate?

  Given ATTACHments and ALTREP are there still people out there who
think support for multipart should be a MAY? If yes, let us know.
(If there are people who say yes, I am fine with keeping it a
MAY!)

> 
> Keep in mind that not all ALTREPs are multipart/alternate or CIDs.
> The multipart/alternate would be the only ones effected - correct?
> (Or I guess they could be multipart/related).


From owner-ietf-calendar@mail.imc.org  Fri Sep 13 15:22:50 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16402
	for <calsch-archive@lists.ietf.org>; Fri, 13 Sep 2002 15:22:49 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8DJDTW09699
	for ietf-calendar-bks; Fri, 13 Sep 2002 12:13:29 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DJDRk09690
	for <ietf-calendar@imc.org>; Fri, 13 Sep 2002 12:13:27 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8DJCedn020956
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <ietf-calendar@imc.org>; Fri, 13 Sep 2002 12:13:28 -0700
Message-ID: <3D8236B9.46D8F278@Royer.com>
Date: Fri, 13 Sep 2002 13:04:25 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
Organization: http://INET-Consulting.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Re: Proposal about multipart etc
References: <OF666BD14B.6BA36727-ON85256C32.00768CB1-85256C32.00772E51@iris.com> <3D810DEE.7948EB97@Royer.com> <3D81FB8C.8CC5A42@oracle.com>
Content-Type: multipart/mixed;
 boundary="------------6C970C83799CEF0B94F82CBE"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multi-part message in MIME format.
--------------6C970C83799CEF0B94F82CBE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

George Babics wrote:

> Shouldn't the CUA be able to detect that an event has a large
> inline attachment, and decide not to get the attachment but get
> the rest of the event? Or if the attachment is too big for
> the CUA, the attachment is not returned? The CUA can display a
> message to the CU that the attachment was too big to download.
> Should the CU not be able to see the event because the attachment
> is too big?

How? We have no such protocol.
The CUA can ask for everything, and if it exceeds the size, it
will get a status error back. How would the CUA know it
was the ATTACH and not the total of all of the properties?

For a CUA that has serious size issues:
A CUA nows what properties it supports. I would assume that
if a CUA has serious size issues, it should only ask for the
properties that it supports. And if it also supports ATTACH and ALTREP,
then *perhaps* a limited memory CUA should separately ask for
those.

Multipart still does not solve the size problem. I do not
think there is a solution If you ask for all of a component,
the size of the result is the sum of all of its body parts. It
is not going to get smaller because the ATTACH or ALTREP value
is in another body part.

We have no way to say:

	SELECT * (except other body parts) FROM VEVENT


And I don't think we need to. Limited memory devices or those
limited to tiny bandwidths will need to just ask for want they
want.

>   An inline attachment can easily get very big, especially, if the
> CUA does not support multipart. However, how often can a DESCRIPTION,
> SUMMARY, number of ATTENDEES, etc., be bigger than the maximum? What
> would a typical maximum be? 1K, 10K, 100K?

'Typical' depends on the implementation and how much the application
owner pays for bandwidth, not CAP the protocol.

> >...
--------------6C970C83799CEF0B94F82CBE
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@Royer.com
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@Royer.com
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard

--------------6C970C83799CEF0B94F82CBE--



From owner-ietf-calendar@mail.imc.org  Mon Sep 16 10:01:27 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05546
	for <calsch-archive@lists.ietf.org>; Mon, 16 Sep 2002 10:01:27 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8GDhN108444
	for ietf-calendar-bks; Mon, 16 Sep 2002 06:43:23 -0700 (PDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GDhMk08440
	for <ietf-calendar@imc.org>; Mon, 16 Sep 2002 06:43:22 -0700 (PDT)
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8GDhIe26264
	for <ietf-calendar@imc.org>; Mon, 16 Sep 2002 06:43:18 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8GDhHC26251
	for <ietf-calendar@imc.org>; Mon, 16 Sep 2002 06:43:17 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8GDhGv27636
	for <ietf-calendar@imc.org>; Mon, 16 Sep 2002 07:43:17 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8GDhEf27568
	for <ietf-calendar@imc.org>; Mon, 16 Sep 2002 07:43:14 -0600 (MDT)
Message-ID: <3D85DFF1.6C586A37@oracle.com>
Date: Mon, 16 Sep 2002 09:43:13 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <OF666BD14B.6BA36727-ON85256C32.00768CB1-85256C32.00772E51@iris.com> <3D810DEE.7948EB97@Royer.com> <3D81FB8C.8CC5A42@oracle.com> <3D8236B9.46D8F278@Royer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Doug Royer wrote:
> 
> George Babics wrote:
> 
> > Shouldn't the CUA be able to detect that an event has a large
> > inline attachment, and decide not to get the attachment but get
> > the rest of the event? Or if the attachment is too big for
> > the CUA, the attachment is not returned? The CUA can display a
> > message to the CU that the attachment was too big to download.
> > Should the CU not be able to see the event because the attachment
> > is too big?
> 
> How? We have no such protocol.
> The CUA can ask for everything, and if it exceeds the size, it
> will get a status error back. How would the CUA know it
> was the ATTACH and not the total of all of the properties?

I know we have no such protocol. My point is that shouldn't the
CUA be able to see the event (except for the attachment) even
though the attachment is too big for it?
 
> 
> For a CUA that has serious size issues:
> A CUA nows what properties it supports. I would assume that
> if a CUA has serious size issues, it should only ask for the
> properties that it supports. And if it also supports ATTACH and ALTREP,
> then *perhaps* a limited memory CUA should separately ask for
> those.
> 
> Multipart still does not solve the size problem. I do not
> think there is a solution If you ask for all of a component,
> the size of the result is the sum of all of its body parts. It
> is not going to get smaller because the ATTACH or ALTREP value
> is in another body part.
> 
> We have no way to say:
> 
>         SELECT * (except other body parts) FROM VEVENT
> 
> And I don't think we need to. Limited memory devices or those
> limited to tiny bandwidths will need to just ask for want they
> want.
> 
> >   An inline attachment can easily get very big, especially, if the
> > CUA does not support multipart. However, how often can a DESCRIPTION,
> > SUMMARY, number of ATTENDEES, etc., be bigger than the maximum? What
> > would a typical maximum be? 1K, 10K, 100K?
> 
> 'Typical' depends on the implementation and how much the application
> owner pays for bandwidth, not CAP the protocol.

  It may not even depend much on the implementation and how much the
owner pays for bandwidth. It will depend much on usage. Most events will
probably have a SUMMARY, a DTSTART, a DTEND/DURATION, a LOCATION, two or
three attendees, an ORGANIZER, a UID, a VERSION, a PRODID, and not much more.
How many bytes can that be? Not very much. However, once you add a huge
attachment to the event, the CU will not be able to see it, if its CUA has
limits to the sizes of objects.

  (Moreover, even though I did not claim that the typical size
may depend on the protocol, I think that it can. The protocol
can decide what properties you need to specify for which commands.
However, I this is a divergence from the main topic of this
thread that I do not have the time to get into.)

  However, as you stated earlier, and related to the "How To Handle
Attachments" thread, CUAs should be wary of attachments, especially
those with bandwidth or memory limits. A CUA may only want to first
detect if a component has an attachment. Then only if the user wants
the attachment, he may "click" on it. Then the CUA will try to download
the attachment. If it is past the CUAs limit, then it gets an error.
(We can do this with the proposal made in the "How To Handle Attachments"
thread.)

  It would also be helpful if we had some suggestions in CAP on how
attachments should be handled.

> 
> > >...

George


From owner-ietf-calendar@mail.imc.org  Mon Sep 16 16:47:19 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16726
	for <calsch-archive@lists.ietf.org>; Mon, 16 Sep 2002 16:47:18 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8GKV1o28163
	for ietf-calendar-bks; Mon, 16 Sep 2002 13:31:01 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GKUxk28156
	for <ietf-calendar@imc.org>; Mon, 16 Sep 2002 13:30:59 -0700 (PDT)
In-Reply-To: <3D80F39D.FCA860E0@Royer.com>
To: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002
Message-ID: <OF9924F4BF.483928DF-ON85256C36.006B3BA1-85256C36.0070921E@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Mon, 16 Sep 2002 16:30:57 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09132002NP|September 13, 2002) at
 09/16/2002 04:24:53 PM,
	Serialize complete at 09/16/2002 04:24:53 PM
Content-Type: multipart/alternative; boundary="=_alternative 007091E885256C36_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 007091E885256C36_=
Content-Type: text/plain; charset="US-ASCII"

Doug asked on 09/12/2002 04:05:49 PM:
>    When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
>    identify the contents of the ATTACHMENT value in the old-values in
>    order to delete them.  When the CS compares the attachment data it is
>    compared in its binary form.  The ATTACHMENT value supplied by the
>    CUA MUST BE valid encoded information.
>
> We should change 'to delete them' to 'to delete or modify them' 
> Last sentence is going to be deleted.
> 
> Would that solve the issue?

Not quite.    The text still only refers to 'inline ATTACHments' (casing 
adjusted to be accurate).  It needs to also address external to store and 
multipart instances too.  Removing 'inline' may achieve that (but I have 
not fully tried all possible cases to confirm this).

The only action that I see as being possibly confusing is mulitple 
concurrent modifications unless you simply expect the CS to delete _any_ 
old ATTACHment and then add the new one(s) in their place (since there is 
no way to match the ATTACHments in the 'old data' w/their corresponding 
mates in the 'new data'). 

This is also true of any property that can be multiinstanced in a single 
entity so explicitly codifying this for all implementors is probably a 
good idea.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 007091E885256C36_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug asked on 09/12/2002 04:05:49 PM:<br>
&gt; &nbsp; &nbsp;When it comes to inline ATTACHMENTs, the CUA only needs
to uniquely<br>
&gt; &nbsp; &nbsp;identify the contents of the ATTACHMENT value in the
old-values in<br>
&gt; &nbsp; &nbsp;order to delete them. &nbsp;When the CS compares the
attachment data it is<br>
&gt; &nbsp; &nbsp;compared in its binary form. &nbsp;The ATTACHMENT value
supplied by the<br>
&gt; &nbsp; &nbsp;CUA MUST BE valid encoded information.<br>
&gt;</tt></font>
<br><font size=2><tt>&gt; We should change 'to delete them' to 'to delete
or modify them' <br>
&gt; Last sentence is going to be deleted.<br>
&gt; <br>
&gt; Would that solve the issue?</tt></font>
<br>
<br><font size=2 face="sans-serif">Not quite. &nbsp; &nbsp;The text still
only refers to 'inline ATTACHments' (casing adjusted to be accurate). &nbsp;It
needs to also address external to store and multipart instances too. &nbsp;Removing
'inline' may achieve that (but I have not fully tried all possible cases
to confirm this).</font>
<br>
<br><font size=2 face="sans-serif">The only action that I see as being
possibly confusing is mulitple concurrent modifications unless you simply
expect the CS to delete _any_ old ATTACHment and then add the new one(s)
in their place (since there is no way to match the ATTACHments in the 'old
data' w/their corresponding mates in the 'new data'). &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">This is also true of any property that
can be multiinstanced in a single entity so explicitly codifying this for
all implementors is probably a good idea.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 007091E885256C36_=--


From owner-ietf-calendar@mail.imc.org  Mon Sep 16 17:12:32 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17562
	for <calsch-archive@lists.ietf.org>; Mon, 16 Sep 2002 17:12:31 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8GL84s29355
	for ietf-calendar-bks; Mon, 16 Sep 2002 14:08:04 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GL83k29351
	for <ietf-calendar@imc.org>; Mon, 16 Sep 2002 14:08:03 -0700 (PDT)
Received: from Royer.com (mail.docutechcorp.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8GL84R2006967
	for <ietf-calendar@imc.org>; Mon, 16 Sep 2002 14:08:05 -0700
Message-ID: <3D864621.9050705@Royer.com>
Date: Mon, 16 Sep 2002 14:59:13 -0600
From: Doug Royer <Doug@royer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
CC: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
References: <OF9924F4BF.483928DF-ON85256C36.006B3BA1-85256C36.0070921E@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080304050709090802030904"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms080304050709090802030904
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug asked on 09/12/2002 04:05:49 PM:
>  >    When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
>  >    identify the contents of the ATTACHMENT value in the old-values in
>  >    order to delete them.  When the CS compares the attachment data it is
>  >    compared in its binary form.  The ATTACHMENT value supplied by the
>  >    CUA MUST BE valid encoded information.
>  >
>  > We should change 'to delete them' to 'to delete or modify them'
>  > Last sentence is going to be deleted.
>  >
>  > Would that solve the issue?
> 
> Not quite.    The text still only refers to 'inline ATTACHments' (casing 
> adjusted to be accurate).  It needs to also address external to store 
> and multipart instances too.  Removing 'inline' may achieve that (but I 
> have not fully tried all possible cases to confirm this).

Yes - I agree. It should not matter if the ATTACH is inline or not.

> The only action that I see as being possibly confusing is mulitple 
> concurrent modifications unless you simply expect the CS to delete _any_ 
> old ATTACHment and then add the new one(s) in their place (since there 
> is no way to match the ATTACHments in the 'old data' w/their 
> corresponding mates in the 'new data').  

With MODIFY, yes you can, you specify the initial part of what makes
each ATTACH unique:

		CMD:MODIFY
		BEGIN:VEVENT		#OLD Attach values
		ATTACH;VALUE=BINARY:lsfjjds121
		ATTACH;VALUE=BINARY:lsfjjds122
		END:VEVENT
		BEGIN:VEVENT		#NEW
		ATTACH;VALUE=BINARY:lsfjjds123........<all of data>...
		ATTACH;VALUE=BINARY:lsfjjds124........<all of data>...
		END:VEVENT


> This is also true of any property that can be multiinstanced in a single 
> entity so explicitly codifying this for all implementors is probably a 
> good idea.

The only limitation is if ALL of those multiinstance properties had
EXACTLY the same value and parameters (which is doubtful).

	
		CMD:MODIFY
		BEGIN:VEVENT		#OLD Attach values
		PROP;param1=a:value1
		PROP;param2=a:value1
		END:VEVENT
		BEGIN:VEVENT		#NEW
		PROP:param1=b:value1
		PROP:param2=b:value1
		END:VEVENT

--------------ms080304050709090802030904
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMoDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBJkwggQCoAMCAQICEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwMTIyMDAw
MDAwWhcNMDIxMDEyMjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALu5M8Oe
P9S38Qpp7q+co8hakIjYegcCXefm5J/+AjAPhn6PeB7CxHQObvRuMBxbHCmzoU2mGwxQGiUH
AqgvvcMYrw01LP4bx+/MysNrpID4+/+G/QiGSqqYKQR2BrArPOzeLe3epDLzM5WFc1BKSFS/
OW5MM2LQVLZuwJ6lTuHDAgMBAAGjggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEw
gZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24n
cyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjAR
BglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiAxODA2OWFmNjdiMzI3M2E1MDIz
NDAxZGMyNTcxZjc2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBACKuMzBrDvgZuvczrWqb4GfNo055My+u
IU23B+rVcPCBbhUEaE/WMcUvVuDpMnASic8sl6mLGPRjr9JqHCQbVBSjzpoLIlLKsHupaXmr
g8he+Nwa83eOBUuUzkJhxcjIRcv2wabyHF3E8HXnIp3nX1A2TM2n6x3lBTxbDkMzQBhzMIIE
mTCCBAKgAwIBAgIQPOZ1ckNS5Z3CqHJP0SwvXTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu
LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVh
bCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMjAxMjIwMDAwMDBaFw0w
MjEwMTIyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2Nh
cGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5k
b3VnQHJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu7kzw54/1LfxCmnu
r5yjyFqQiNh6BwJd5+bkn/4CMA+Gfo94HsLEdA5u9G4wHFscKbOhTaYbDFAaJQcCqC+9wxiv
DTUs/hvH78zKw2ukgPj7/4b9CIZKqpgpBHYGsCs87N4t7d6kMvMzlYVzUEpIVL85bkwzYtBU
tm7AnqVO4cMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZI
AYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMw
YgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBp
bmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG
+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDE4MDY5YWY2N2IzMjczYTUwMjM0MDFkYzI1
NzFmNzY0MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNz
MS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAIq4zMGsO+Bm69zOtapvgZ82jTnkzL64hTbcH6tVw
8IFuFQRoT9YxxS9W4OkycBKJzyyXqYsY9GOv0mocJBtUFKPOmgsiUsqwe6lpeauDyF743Brz
d44FS5TOQmHFyMhFy/bBpvIcXcTwdecinedfUDZMzafrHeUFPFsOQzNAGHMxggM0MIIDMAIB
ATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg
SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNz
IDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQPOZ1
ckNS5Z3CqHJP0SwvXTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wMjA5MTYyMDU5MTNaMCMGCSqGSIb3DQEJBDEWBBQGsjk2t3gi
PrWaq0MhG5cBEQE29zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYLKoZIhvcN
AQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEBBQAEgYCj4uv7FB7HzaScR8MOZm3L
R9IKDMjEFAx1ThQYIyDbrwLSEowhSew3BC0cQc1Ou2DT5LdhYXhy2p1XZeIJuGNJTRTQeTsl
S2hmVokwFXkuixKL3zbpBqUpob8utOk0dYEVXSwKZKsP6zKSgCE0KzBaZZXL3gOioFKcOESH
svwBCwAAAAAAAA==
--------------ms080304050709090802030904--



From owner-ietf-calendar@mail.imc.org  Tue Sep 17 07:06:10 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10178
	for <calsch-archive@lists.ietf.org>; Tue, 17 Sep 2002 07:06:09 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8HAufp02961
	for ietf-calendar-bks; Tue, 17 Sep 2002 03:56:41 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HAuek02956
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 03:56:40 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 39A6815570; Tue, 17 Sep 2002 12:56:34 +0200 (CEST)
Date: Tue, 17 Sep 2002 12:56:33 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Revised proposal
Message-ID: <20020917105633.GE39963@inet.it>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF"
Content-Disposition: inline
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>



--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi all,

I updated the proposal with all (I think) the feedback that was
posted on this list; modified lines are marked with a "> " at
the beginning of the line. I hope MUAs don't mess us too much,
so I'm also attaching the file.
There are a few points I need feedback on, I marked those with
notes.

I also added examples, I hope they are useful.




 1 Multipart in CAP	[note: addition/revision to 3.3.1 in current draft]

The BEEP data exchanged in CAP may take different forms depending on
the data being exchanged and the capabilities of the CUA and the CS.

> [note: I propose this change from my original text.]
> If data can be sent in different forms, it is advisable to send it
> as text/calendar. In particular, most commands SHOULD be sent as
> test/calendar.

 1.1 text/calendar

If the payload of a BEEP packet is of type text/calendar, it MUST
conform to [iCAL] iCalendar format. This is the only format which
all CAP implementations MUST accept.

 1.2 multipart/related

> [note: this amendment was proposed by George Babics; there was one
>  objection but didn't provide evidence to support the need for more
>  than one text/calendar part. If anybody care about this I can change
>  it back to the original text.]
> If the exchanged packets contain multipart/related payload, they MUST
> contain exactly one text/calendar parts, which must conform to [iCAL]
> iCalendar format. If a CUA or a CS doesn't support this form, they MUST
> respond with an appropriate REQUEST-STATUS (TBD).

If needed, additional data can be transmitted in addidional body
parts using the appropriate MIME type; in particular, this can be
used for attachments. Additional body parts are referred to using
CID: etc.

 2 Multipart negotiation

A CUA and a CS SHOULD negotiate the level of multipart support.

>  This is done by sending the GET-CAPABILITY command and checking
>  for the values of the MULTIPART property. The negotiation can be
>  started by either of the endpoints.

An endpoint should assume the other endpoint can't do multipart, and send
a GET-CAPABILITY command as text/calendar. If the answer states that
the other party supports multipart, it can send subsequent commands
using the appropriate form.

>  In the example below, the CS supports multipart/related in addition
>  to text/calendar. However, the CUA sent no MULTIPART property, which
>  indicates it doesn't support any, so any subsequent data exchange
>  must only use test/calendar.

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:The CUA's PRODID
C: CMD;ID=12345:GET-CAPABILITY
C: END:VCALENDAR

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:The CS's PRODID
S: CMD;ID=12345:REPLY
S: BEGIN:VREPLY
S: ...
S: MULTIPART:related, alternative, mixed
S: ...
S: END:VREPLY
S: END:VCALENDAR

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:The CS's PRODID
S: CMD;ID=12346:GET-CAPABILITY
S: END:VCALENDAR

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:The CUA's PRODID
C: CMD;ID=12345:REPLY
C: BEGIN:VREPLY
C: ...
C: ...
C: END:VREPLY
C: END:VCALENDAR


> [note: I initially put this in to solicit discussion. If nobody
>  cares I will remove this sentence.]
As an alternative, a party may opt to start using multipart and switch
to the simpler text/calendar form if it receives an error.


 3 Considerations

 3.1 Graceful degradation

If both parties support multipart, each party may opt to use the
encoding it prefers. However, text/calendar support is mandatory,
which in particular means a CS MUST use text/calendar in replies
to commands if the party only supports that form, with no loss of
data except as indicated in 3.2.

In particular, if the CUA only supports text/calendar:

 - all replies to commands with multiple targets or multiple queries, as
well as replies containing separate components with different METHODs,
must be sent with different iCalendar objects in the same text/calendar

[note: add more here if we want to. I know this is already present
in iCal]

 3.2 Limitations

 3.2.1 cid: URI

A CUA or a CS which doesn't support multipart can't properly handle
properties with a cid: URI value; this affects ATTACH properties and
any property which allows the ALTREP parameter.

> [note: this sentence generated discussion on the list, but in fact
>  it's the same issue as for any URI a CUA is unable to access, so
>  it's really just a matter of user interface - and should be removed
>  from here.]
> A limited CUA SHOULD inform the user that there is an attachment or
> ALTREP but it is not able to access it.
It should also provide alternative ways
to attach files to outgoing components. One method would be to store
> the file on an appropriate file store and store the URI; or it could
> opt to inline the referenced data.

A limited CS SHOULD try not to lose ATTACHments. One method would be
to provide an iMIP+CAP client that stores attachments on any appropriate
file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
> ATTACH properties to reference the appropriate URI. Another possibility
> would be to inline the referenced data.

It is advisable that CS which have no limitations, but want to support
clients with limited capabilities, do the same conversion, either at
time or retrieval time.

> In the first example, multipart was negotiated earlier, so the CS
> knows it can send multipart:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: multipart/related; boundary="boundary-example-1";type=text/calendar
   S: 
   S: --boundary-example-1
   S: 
   S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   S: Content-Transfer-Encoding: 7bit
   S: Content-Disposition: attachment; filename="event.vcs"
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@example.com
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH:cid:123456789@example.com
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR
   S: 
   S: --boundary-example-1
   S: Content-Type: application/msword; name="FieldReport.doc"
   S: Content-Transfer-Encoding: base64
   S: Content-Disposition: inline; filename="FieldReport.doc"
   S: Content-ID: <123456789@example.com>
   S: 
   S: 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   S: AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
   S: 
   S: --boundary-example-1--

> In the next example, multipart negotiatiotian failed, so the CS can't
> use multipart. The attachment is converted to inline.

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: text/calendar
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@example.com
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH;ENCODING=base64;FMTTYPE=application/msword;VALUE=BINARY:
   S:  0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   S:  AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR

> In the next example, the CS saved the ATTACHment on an external store:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: text/calendar
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@example.com
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH;FMTTYPE=application/msword:
   S:  webdav://example.com/calsvr.example.com-8739701987387771
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR








Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=proposal

 1 Multipart in CAP	[note: addition/revision to 3.3.1 in current draft]

The BEEP data exchanged in CAP may take different forms depending on
the data being exchanged and the capabilities of the CUA and the CS.

> [note: I propose this change from my original text.]
> If data can be sent in different forms, it is advisable to send it
> as text/calendar. In particular, most commands SHOULD be sent as
> test/calendar.

 1.1 text/calendar

If the payload of a BEEP packet is of type text/calendar, it MUST
conform to [iCAL] iCalendar format. This is the only format which
all CAP implementations MUST accept.

 1.2 multipart/related

> [note: this amendment was proposed by George Babics; there was one
>  objection but didn't provide evidence to support the need for more
>  than one text/calendar part. If anybody care about this I can change
>  it back to the original text.]
> If the exchanged packets contain multipart/related payload, they MUST
> contain exactly one text/calendar parts, which must conform to [iCAL]
> iCalendar format. If a CUA or a CS doesn't support this form, they MUST
> respond with an appropriate REQUEST-STATUS (TBD).

If needed, additional data can be transmitted in addidional body
parts using the appropriate MIME type; in particular, this can be
used for attachments. Additional body parts are referred to using
CID: etc.

 2 Multipart negotiation

A CUA and a CS SHOULD negotiate the level of multipart support.

>  This is done by sending the GET-CAPABILITY command and checking
>  for the values of the MULTIPART property. The negotiation can be
>  started by either of the endpoints.

An endpoint should assume the other endpoint can't do multipart, and send
a GET-CAPABILITY command as text/calendar. If the answer states that
the other party supports multipart, it can send subsequent commands
using the appropriate form.

>  In the example below, the CS supports multipart/related in addition
>  to text/calendar. However, the CUA sent no MULTIPART property, which
>  indicates it doesn't support any, so any subsequent data exchange
>  must only use test/calendar.

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:The CUA's PRODID
C: CMD;ID=12345:GET-CAPABILITY
C: END:VCALENDAR

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:The CS's PRODID
S: CMD;ID=12345:REPLY
S: BEGIN:VREPLY
S: ...
S: MULTIPART:related, alternative, mixed
S: ...
S: END:VREPLY
S: END:VCALENDAR

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:The CS's PRODID
S: CMD;ID=12346:GET-CAPABILITY
S: END:VCALENDAR

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:The CUA's PRODID
C: CMD;ID=12345:REPLY
C: BEGIN:VREPLY
C: ...
C: ...
C: END:VREPLY
C: END:VCALENDAR


> [note: I initially put this in to solicit discussion. If nobody
>  cares I will remove this sentence.]
As an alternative, a party may opt to start using multipart and switch
to the simpler text/calendar form if it receives an error.


 3 Considerations

 3.1 Graceful degradation

If both parties support multipart, each party may opt to use the
encoding it prefers. However, text/calendar support is mandatory,
which in particular means a CS MUST use text/calendar in replies
to commands if the party only supports that form, with no loss of
data except as indicated in 3.2.

In particular, if the CUA only supports text/calendar:

 - all replies to commands with multiple targets or multiple queries, as
well as replies containing separate components with different METHODs,
must be sent with different iCalendar objects in the same text/calendar

[note: add more here if we want to. I know this is already present
in iCal]

 3.2 Limitations

 3.2.1 cid: URI

A CUA or a CS which doesn't support multipart can't properly handle
properties with a cid: URI value; this affects ATTACH properties and
any property which allows the ALTREP parameter.

> [note: this sentence generated discussion on the list, but in fact
>  it's the same issue as for any URI a CUA is unable to access, so
>  it's really just a matter of user interface - and should be removed
>  from here.]
> A limited CUA SHOULD inform the user that there is an attachment or
> ALTREP but it is not able to access it.
It should also provide alternative ways
to attach files to outgoing components. One method would be to store
> the file on an appropriate file store and store the URI; or it could
> opt to inline the referenced data.

A limited CS SHOULD try not to lose ATTACHments. One method would be
to provide an iMIP+CAP client that stores attachments on any appropriate
file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
> ATTACH properties to reference the appropriate URI. Another possibility
> would be to inline the referenced data.

It is advisable that CS which have no limitations, but want to support
clients with limited capabilities, do the same conversion, either at
time or retrieval time.

> In the first example, multipart was negotiated earlier, so the CS
> knows it can send multipart:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: multipart/related; boundary="boundary-example-1";type=text/calendar
   S: 
   S: --boundary-example-1
   S: 
   S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   S: Content-Transfer-Encoding: 7bit
   S: Content-Disposition: attachment; filename="event.vcs"
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@example.com
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH:cid:123456789@example.com
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR
   S: 
   S: --boundary-example-1
   S: Content-Type: application/msword; name="FieldReport.doc"
   S: Content-Transfer-Encoding: base64
   S: Content-Disposition: inline; filename="FieldReport.doc"
   S: Content-ID: <123456789@example.com>
   S: 
   S: 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   S: AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
   S: 
   S: --boundary-example-1--

> In the next example, multipart negotiatiotian failed, so the CS can't
> use multipart. The attachment is converted to inline.

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: text/calendar
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@example.com
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH;ENCODING=base64;FMTTYPE=application/msword;VALUE=BINARY:
   S:  0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   S:  AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR

> In the next example, the CS saved the ATTACHment on an external store:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: text/calendar
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@example.com
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH;FMTTYPE=application/msword:
   S:  webdav://example.com/calsvr.example.com-8739701987387771
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR



--3MwIy2ne0vdjdPXF--


From owner-ietf-calendar@mail.imc.org  Tue Sep 17 10:33:27 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16941
	for <calsch-archive@lists.ietf.org>; Tue, 17 Sep 2002 10:33:26 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8HE6Eb15210
	for ietf-calendar-bks; Tue, 17 Sep 2002 07:06:14 -0700 (PDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HE6Dk15206
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 07:06:13 -0700 (PDT)
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8HE69e13257
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 07:06:09 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8HE69C13241
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 07:06:09 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8HE68v29093
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 08:06:08 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8HE67f29050
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 08:06:07 -0600 (MDT)
Message-ID: <3D8736CD.14754EC4@oracle.com>
Date: Tue, 17 Sep 2002 10:06:05 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
References: <20020917105633.GE39963@inet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



I am fine with this proposal.
People, give your vote in soon so we can hopefully close this
issue and move on.

A couple of small comments. See below.

Andrea Campi wrote:
> 
> Hi all,
> 

...

> If needed, additional data can be transmitted in addidional body
> parts using the appropriate MIME type; in particular, this can be
> used for attachments. Additional body parts are referred to using
> CID: etc.

 We should refer to the appropriate RFC(s) ...

...

> 
> > [note: I initially put this in to solicit discussion. If nobody
> >  cares I will remove this sentence.]
> As an alternative, a party may opt to start using multipart and switch
> to the simpler text/calendar form if it receives an error.

  I am OK with removing this.

...

> > [note: this sentence generated discussion on the list, but in fact
> >  it's the same issue as for any URI a CUA is unable to access, so
> >  it's really just a matter of user interface - and should be removed
> >  from here.]
> > A limited CUA SHOULD inform the user that there is an attachment or
> > ALTREP but it is not able to access it.
> It should also provide alternative ways
> to attach files to outgoing components. One method would be to store
> > the file on an appropriate file store and store the URI; or it could
> > opt to inline the referenced data.

  I am OK with removing it.
  

George


From owner-ietf-calendar@mail.imc.org  Tue Sep 17 13:11:40 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22137
	for <calsch-archive@lists.ietf.org>; Tue, 17 Sep 2002 13:11:40 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8HH1IM25570
	for ietf-calendar-bks; Tue, 17 Sep 2002 10:01:18 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HH1Gk25566
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 10:01:16 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8HH1GR2015275
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 10:01:16 -0700
Message-ID: <3D875DB4.80407@Royer.com>
Date: Tue, 17 Sep 2002 10:52:04 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040500020205000803080306"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms040500020205000803080306
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


 >  1.1 text/calendar
 >
 > If the payload of a BEEP packet is of type text/calendar, it MUST
 > conform to [iCAL] iCalendar format. This is the only format which
 > all CAP implementations MUST accept.

How about:

   If the payload of a BEEP packet contains a text/calendar body part,
   it MUST ...

because:

A multipart message is of type 'multipart' (not text/calendar), and it
can contain one or more text/calendar body parts, each of which may
have references to other body parts in the same MIME object - correct?

 >  1.2 multipart/related

How about '1.2 multipart' as there are several multipart types.

 >>[note: this amendment was proposed by George Babics; there was one
 >> objection but didn't provide evidence to support the need for more
 >> than one text/calendar part. If anybody care about this I can change
 >> it back to the original text.]
 >>If the exchanged packets contain multipart/related payload, they MUST
 >>contain exactly one text/calendar parts, which must conform to [iCAL]
 >>iCalendar format. If a CUA or a CS doesn't support this form, they MUST
 >>respond with an appropriate REQUEST-STATUS (TBD).
 >
 >
 > If needed, additional data can be transmitted in addidional body
 > parts using the appropriate MIME type; in particular, this can be
 > used for attachments. Additional body parts are referred to using
 > CID: etc.
 >
 >  2 Multipart negotiation
 >
 > A CUA and a CS SHOULD negotiate the level of multipart support.

How about:

   A CS MUST send the MULTIPART capability and a CUA MUST send
   the MULTIPART capability when the CUA supports sending CAPABILITY.

   If the CUA does not support CAPABILITY, the CS MUST assume that
   the CUA does not support any multipart.

   The value of the MULTIPART capability may be empty meaning that
   no multipart is supported by that endpoint.


 >
 >  3 Considerations
 >
 >  3.1 Graceful degradation
 >
 > If both parties support multipart, each party may opt to use the
 > encoding it prefers. However, text/calendar support is mandatory,
 > which in particular means a CS MUST use text/calendar in replies
 > to commands if the party only supports that form, with no loss of
 > data except as indicated in 3.2.

Do you mean 'inline' vs 'body part' as 'encoding' is BASE64, binary, ...?

Or do you mean multipart vs single body part?

 > In particular, if the CUA only supports text/calendar:

 >  - all replies to commands with multiple targets or multiple queries, as
 > well as replies containing separate components with different METHODs,
 > must be sent with different iCalendar objects in the same text/calendar

You can't mix METHODs in the same MIME object (That's a restriction
from one of the 244[567] RFC's). So each endpoint that does not
support multipart MUST be able to receive the following as one
command reply:

     (1) One MIME object of type text/calendar. (Not multipart)
         And each text/calendar must contain one or more iCalendar objects.
         All with the same METHOD.

     (2) Multiple MIME objects each of type text/calendar (Not multipart)
         And each text/calendar must contain one or more iCalendar objects
         of the same METHOD.

And each endpoint that is able to receive multipart must in addition
to (1) and (2) above be able to receive:

     (3) A single multipart MIME object of the types it specified in its
         CAPABILITY reply. Where each MIME object must contain at least
         one text/calendar and may contain other body parts. And each
         text/calendar object must contain one or more iCalendar objects.
         All iCalendar objects in all of the text/calendar body parts,
         must be of the same METHOD.

     (4) Multiple multipart MIME objects of the types it specified in its
         CAPABILITY reply. Where each MIME object must contain at least
         one text/calendar and may contain other body parts. And each
         text/calendar object must contain one or more iCalendar objects.
         All iCalendar objects in all of the text/calendar body parts
         with a single MIME object, must be of the same METHOD.

 >  3.2 Limitations
 >
 >  3.2.1 cid: URI
 >
 > A CUA or a CS which doesn't support multipart can't properly handle
 > properties with a cid: URI value; this affects ATTACH properties and
 > any property which allows the ALTREP parameter.

A CUA or CS can always inline attachments or make them body parts
when supported. This has no effect on a CUA or CS ability to
support ATTACH. The size limit is a separate issue.

If a CUA or CS does not support multipart, then all ALTREP
values must be stored external to the text/calendar object
and can not be transmitted using CAP.

I think it is out of scope for CAP to specify how.

 >>A limited CUA SHOULD inform the user that there is an attachment or
 >>ALTREP but it is not able to access it.
 >
 > It should also provide alternative ways
 > to attach files to outgoing components. One method would be to store
 > the file on an appropriate file store and store the URI; or it could
 > opt to inline the referenced data.

I would say:

  WHEN the other endpoint does not support multipart then:

   (1) ATTACH values MUST BE inlined. If it can not fit because
       of size limits, then a size error must be given.

   (2) ALTREP values that are in other body parts to the same MIME object
       can not be transmitted using CAP. A CUS or CS implementation may
       provide storage for the ALTREP value and modify the ALTREP value
       in the iCalendar object to point to the external value. How this is
       handled is not specified in CAP. Or they may issue an error.




--------------ms040500020205000803080306
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMoDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBJkwggQCoAMCAQICEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwMTIyMDAw
MDAwWhcNMDIxMDEyMjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALu5M8Oe
P9S38Qpp7q+co8hakIjYegcCXefm5J/+AjAPhn6PeB7CxHQObvRuMBxbHCmzoU2mGwxQGiUH
AqgvvcMYrw01LP4bx+/MysNrpID4+/+G/QiGSqqYKQR2BrArPOzeLe3epDLzM5WFc1BKSFS/
OW5MM2LQVLZuwJ6lTuHDAgMBAAGjggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEw
gZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24n
cyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjAR
BglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiAxODA2OWFmNjdiMzI3M2E1MDIz
NDAxZGMyNTcxZjc2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBACKuMzBrDvgZuvczrWqb4GfNo055My+u
IU23B+rVcPCBbhUEaE/WMcUvVuDpMnASic8sl6mLGPRjr9JqHCQbVBSjzpoLIlLKsHupaXmr
g8he+Nwa83eOBUuUzkJhxcjIRcv2wabyHF3E8HXnIp3nX1A2TM2n6x3lBTxbDkMzQBhzMIIE
mTCCBAKgAwIBAgIQPOZ1ckNS5Z3CqHJP0SwvXTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu
LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVh
bCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMjAxMjIwMDAwMDBaFw0w
MjEwMTIyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2Nh
cGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5k
b3VnQHJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu7kzw54/1LfxCmnu
r5yjyFqQiNh6BwJd5+bkn/4CMA+Gfo94HsLEdA5u9G4wHFscKbOhTaYbDFAaJQcCqC+9wxiv
DTUs/hvH78zKw2ukgPj7/4b9CIZKqpgpBHYGsCs87N4t7d6kMvMzlYVzUEpIVL85bkwzYtBU
tm7AnqVO4cMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZI
AYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMw
YgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBp
bmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG
+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDE4MDY5YWY2N2IzMjczYTUwMjM0MDFkYzI1
NzFmNzY0MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNz
MS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAIq4zMGsO+Bm69zOtapvgZ82jTnkzL64hTbcH6tVw
8IFuFQRoT9YxxS9W4OkycBKJzyyXqYsY9GOv0mocJBtUFKPOmgsiUsqwe6lpeauDyF743Brz
d44FS5TOQmHFyMhFy/bBpvIcXcTwdecinedfUDZMzafrHeUFPFsOQzNAGHMxggM0MIIDMAIB
ATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg
SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNz
IDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQPOZ1
ckNS5Z3CqHJP0SwvXTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wMjA5MTcxNjUyMDRaMCMGCSqGSIb3DQEJBDEWBBQipEh0+hm+
znCytNBf4IYA2XjhvDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYLKoZIhvcN
AQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEBBQAEgYB+memBVOOI1usv5oFYZ4p0
1E+SQjDHYWOChuYSYGWB8Kkvl1K4jmVKfHfzNjBduZt7pZmJCGqoon0jYxnsVN2dzhJ3Mh85
BUEH65KV9TKNHvMgcLnoP8ffjXl9nln+TUJnKxqa0+B45PO2gWwCiTi4VdOwCJf9eKsKfEJw
kaKHewAAAAAAAA==
--------------ms040500020205000803080306--



From owner-ietf-calendar@mail.imc.org  Tue Sep 17 14:34:53 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25334
	for <calsch-archive@lists.ietf.org>; Tue, 17 Sep 2002 14:34:53 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8HIPaF00226
	for ietf-calendar-bks; Tue, 17 Sep 2002 11:25:36 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HIPYk00221
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 11:25:35 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 87762155BE; Tue, 17 Sep 2002 20:25:35 +0200 (CEST)
Date: Tue, 17 Sep 2002 20:25:35 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
Message-ID: <20020917182534.GF39963@inet.it>
References: <3D875DB4.80407@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D875DB4.80407@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Tue, Sep 17, 2002 at 10:52:04AM -0600, Doug Royer wrote:
> 
> >  1.1 text/calendar
> >
> > If the payload of a BEEP packet is of type text/calendar, it MUST
> > conform to [iCAL] iCalendar format. This is the only format which
> > all CAP implementations MUST accept.
> 
> How about:
> 
>   If the payload of a BEEP packet contains a text/calendar body part,
>   it MUST ...

How about:

    If the payload of a BEEP packet contains exactly one text/calendar
    body part, it MUST ...

Is this what you mean?

> 
> because:
> 
> A multipart message is of type 'multipart' (not text/calendar), and it
> can contain one or more text/calendar body parts, each of which may
> have references to other body parts in the same MIME object - correct?

Right but in 1.1 I'm talking about text/calendar only, as in an endpoint
which doesn't support any multipart.

> >  1.2 multipart/related
> 
> How about '1.2 multipart' as there are several multipart types.

Yes

> >  2 Multipart negotiation
> >
> > A CUA and a CS SHOULD negotiate the level of multipart support.
> 
> How about:
> 
>   A CS MUST send the MULTIPART capability and a CUA MUST send
>   the MULTIPART capability when the CUA supports sending CAPABILITY.
> 
>   If the CUA does not support CAPABILITY, the CS MUST assume that
>   the CUA does not support any multipart.
> 
>   The value of the MULTIPART capability may be empty meaning that
>   no multipart is supported by that endpoint.

I like your text but it should be in addition to what I proposed -
you mention HOW the negotiation works, but not that it SHOULD (or
MUST, if you prefer) happen. So in addition to your text:

    Both endpoints SHOULD (or MUST) send the GET-CAPABILITY command
    before using multipart objects.

> >
> >  3 Considerations
> >
> >  3.1 Graceful degradation
> >
> > If both parties support multipart, each party may opt to use the
> > encoding it prefers. However, text/calendar support is mandatory,
> > which in particular means a CS MUST use text/calendar in replies
> > to commands if the party only supports that form, with no loss of
> > data except as indicated in 3.2.
> 
> Do you mean 'inline' vs 'body part' as 'encoding' is BASE64, binary, ...?
> 
> Or do you mean multipart vs single body part?

I agree this sentence could be written better, but I'm not sure I
understand your question. How about:

    If a CUA doesn't support multipart, the CS MUST still send all
    meaningful data. To this end, it might rewrite data as it sees
    fit, as detailed in 3.2.

Then again, it doesn't seem to be terribly useful so I might as well
remove it.

> > In particular, if the CUA only supports text/calendar:
> 
> >  - all replies to commands with multiple targets or multiple queries, as
> > well as replies containing separate components with different METHODs,
> > must be sent with different iCalendar objects in the same text/calendar
> 
> You can't mix METHODs in the same MIME object (That's a restriction
> from one of the 244[567] RFC's). So each endpoint that does not

Well, it's in RFC2447, and in the recent thread we didn't reach a
consensus whether we are exchanging true iMIP messages (and therefore
bound to RFC2447) or iTIP messages. I'd say CAP is a different binding,
at the same level as iMIP.

Obviously we need to agree on this before going on.

> support multipart MUST be able to receive the following as one
> command reply:
> 
>     (1) One MIME object of type text/calendar. (Not multipart)
>         And each text/calendar must contain one or more iCalendar objects.
>         All with the same METHOD.
> 
>     (2) Multiple MIME objects each of type text/calendar (Not multipart)
>         And each text/calendar must contain one or more iCalendar objects
>         of the same METHOD.

Do you mean (2) can be used with one text/calendar object per ANS in
a ANS/NUL reply? If so, I agree.

> And each endpoint that is able to receive multipart must in addition
> to (1) and (2) above be able to receive:
> 
>     (3) A single multipart MIME object of the types it specified in its
>         CAPABILITY reply. Where each MIME object must contain at least
>         one text/calendar and may contain other body parts. And each
>         text/calendar object must contain one or more iCalendar objects.
>         All iCalendar objects in all of the text/calendar body parts,
>         must be of the same METHOD.
> 
>     (4) Multiple multipart MIME objects of the types it specified in its
>         CAPABILITY reply. Where each MIME object must contain at least
>         one text/calendar and may contain other body parts. And each
>         text/calendar object must contain one or more iCalendar objects.
>         All iCalendar objects in all of the text/calendar body parts
>         with a single MIME object, must be of the same METHOD.

> >  3.2 Limitations
> >
> >  3.2.1 cid: URI
> >
> > A CUA or a CS which doesn't support multipart can't properly handle
> > properties with a cid: URI value; this affects ATTACH properties and
> > any property which allows the ALTREP parameter.
> 
> A CUA or CS can always inline attachments or make them body parts
> when supported. This has no effect on a CUA or CS ability to
> support ATTACH. The size limit is a separate issue.

I agree.  Note that I wrote "can't properly handle properties with a
cid: URI value". I mean exactly that: if no multipart is usable in this
session, an endpoint must examine the value and if they contain a cid:
URI take corrective measures, which might be inlining or storing
externally.

> If a CUA or CS does not support multipart, then all ALTREP
> values must be stored external to the text/calendar object
> and can not be transmitted using CAP.
> 
> I think it is out of scope for CAP to specify how.

I agree it's out of scopr to specify how, but it's in scope to state
this must be done.

> 
> >>A limited CUA SHOULD inform the user that there is an attachment or
> >>ALTREP but it is not able to access it.
> >
> > It should also provide alternative ways
> > to attach files to outgoing components. One method would be to store
> > the file on an appropriate file store and store the URI; or it could
> > opt to inline the referenced data.
> 
> I would say:
> 
>  WHEN the other endpoint does not support multipart then:
> 
>   (1) ATTACH values MUST BE inlined. If it can not fit because
>       of size limits, then a size error must be given.
> 
>   (2) ALTREP values that are in other body parts to the same MIME object
>       can not be transmitted using CAP. A CUS or CS implementation may
>       provide storage for the ALTREP value and modify the ALTREP value
>       in the iCalendar object to point to the external value. How this is
>       handled is not specified in CAP. Or they may issue an error.
> 

I don't see why external storage is not applicable to (1), too. I
think providing an alternative here is acceptable. Besides, if we
don't specify this, a compliant CS can still use external storage
and the CUA wouldn't even notice, so we can't forbid extenal storage
even if we wanted to...

Bye,
	Andrea


-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Tue Sep 17 17:16:12 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01185
	for <calsch-archive@lists.ietf.org>; Tue, 17 Sep 2002 17:16:12 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8HL95308632
	for ietf-calendar-bks; Tue, 17 Sep 2002 14:09:05 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HL93k08627
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 14:09:03 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8HL94R2017084
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 14:09:05 -0700
Message-ID: <3D8797C6.40001@Royer.com>
Date: Tue, 17 Sep 2002 14:59:50 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
References: <3D875DB4.80407@Royer.com> <20020917182534.GF39963@inet.it>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080509060801080503000602"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms080509060801080503000602
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Andrea Campi wrote:
> On Tue, Sep 17, 2002 at 10:52:04AM -0600, Doug Royer wrote:
> 
>>> 1.1 text/calendar
>>>
>>>If the payload of a BEEP packet is of type text/calendar, it MUST
>>>conform to [iCAL] iCalendar format. This is the only format which
>>>all CAP implementations MUST accept.
>>
>>How about:
>>
>>  If the payload of a BEEP packet contains a text/calendar body part,
>>  it MUST ...
> 
> 
> How about:
> 
>     If the payload of a BEEP packet contains exactly one text/calendar
>     body part, it MUST ...
> 
> Is this what you mean?

With your note (below - that it means - multipart) - yes.

> 
>>because:
>>
>>A multipart message is of type 'multipart' (not text/calendar), and it
>>can contain one or more text/calendar body parts, each of which may
>>have references to other body parts in the same MIME object - correct?
> 
> 
> Right but in 1.1 I'm talking about text/calendar only, as in an endpoint
> which doesn't support any multipart.

  ---

>>> 2 Multipart negotiation
>>>
>>>A CUA and a CS SHOULD negotiate the level of multipart support.
>>
>>How about:
>>
>>  A CS MUST send the MULTIPART capability and a CUA MUST send
>>  the MULTIPART capability when the CUA supports sending CAPABILITY.
>>
>>  If the CUA does not support CAPABILITY, the CS MUST assume that
>>  the CUA does not support any multipart.
>>
>>  The value of the MULTIPART capability may be empty meaning that
>>  no multipart is supported by that endpoint.
> 
> 
> I like your text but it should be in addition to what I proposed -
> you mention HOW the negotiation works, but not that it SHOULD (or
> MUST, if you prefer) happen. So in addition to your text:
> 
>     Both endpoints SHOULD (or MUST) send the GET-CAPABILITY command
>     before using multipart objects.

Re-read it 'MUST' is used 3 times. Each end MUST tell the
other if it supports MULTIPART. Otherwise things will not work.

>>support multipart MUST be able to receive the following as one
>>command reply:
>>
>>    (1) One MIME object of type text/calendar. (Not multipart)
>>        And each text/calendar must contain one or more iCalendar objects.
>>        All with the same METHOD.
>>
>>    (2) Multiple MIME objects each of type text/calendar (Not multipart)
>>        And each text/calendar must contain one or more iCalendar objects
>>        of the same METHOD.
> 
> 
> Do you mean (2) can be used with one text/calendar object per ANS in
> a ANS/NUL reply? If so, I agree.

Currently I have left BEEP out of it, I mean the the CS or CUA
can send one or more text/calendar MIME objects, each with a unique
METHOD. And each can contain multiple iCalendar objects.

>>If a CUA or CS does not support multipart, then all ALTREP
>>values must be stored external to the text/calendar object
>>and can not be transmitted using CAP.
>>
>>I think it is out of scope for CAP to specify how.
> 
> 
> I agree it's out of scopr to specify how, but it's in scope to state
> this must be done.

I disagree - the endpoint MUST do it OR send an error.
My CELL phone will not be exporting files - as an example,
even if it can do body part ATTACH and body part ALTREP.

 >>>>A limited CUA SHOULD inform the user that there is an attachment or
 >>>>ALTREP but it is not able to access it.
 >>>
 >>>It should also provide alternative ways
 >>>to attach files to outgoing components. One method would be to store
 >>>the file on an appropriate file store and store the URI; or it could
 >>>opt to inline the referenced data.
 >>
 >>I would say:
 >>
 >> WHEN the other endpoint does not support multipart then:
 >>
 >>  (1) ATTACH values MUST BE inlined. If it can not fit because
 >>      of size limits, then a size error must be given.
 >
 >
> 
> I don't see why external storage is not applicable to (1), too. I
> think providing an alternative here is acceptable. Besides, if we
> don't specify this, a compliant CS can still use external storage
> and the CUA wouldn't even notice, so we can't forbid extenal storage
> even if we wanted to...

I agree.




--------------ms080509060801080503000602
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMoDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBJkwggQCoAMCAQICEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwMTIyMDAw
MDAwWhcNMDIxMDEyMjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALu5M8Oe
P9S38Qpp7q+co8hakIjYegcCXefm5J/+AjAPhn6PeB7CxHQObvRuMBxbHCmzoU2mGwxQGiUH
AqgvvcMYrw01LP4bx+/MysNrpID4+/+G/QiGSqqYKQR2BrArPOzeLe3epDLzM5WFc1BKSFS/
OW5MM2LQVLZuwJ6lTuHDAgMBAAGjggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEw
gZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24n
cyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjAR
BglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiAxODA2OWFmNjdiMzI3M2E1MDIz
NDAxZGMyNTcxZjc2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBACKuMzBrDvgZuvczrWqb4GfNo055My+u
IU23B+rVcPCBbhUEaE/WMcUvVuDpMnASic8sl6mLGPRjr9JqHCQbVBSjzpoLIlLKsHupaXmr
g8he+Nwa83eOBUuUzkJhxcjIRcv2wabyHF3E8HXnIp3nX1A2TM2n6x3lBTxbDkMzQBhzMIIE
mTCCBAKgAwIBAgIQPOZ1ckNS5Z3CqHJP0SwvXTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu
LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVh
bCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMjAxMjIwMDAwMDBaFw0w
MjEwMTIyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2Nh
cGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5k
b3VnQHJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu7kzw54/1LfxCmnu
r5yjyFqQiNh6BwJd5+bkn/4CMA+Gfo94HsLEdA5u9G4wHFscKbOhTaYbDFAaJQcCqC+9wxiv
DTUs/hvH78zKw2ukgPj7/4b9CIZKqpgpBHYGsCs87N4t7d6kMvMzlYVzUEpIVL85bkwzYtBU
tm7AnqVO4cMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZI
AYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMw
YgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBp
bmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG
+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDE4MDY5YWY2N2IzMjczYTUwMjM0MDFkYzI1
NzFmNzY0MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNz
MS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAIq4zMGsO+Bm69zOtapvgZ82jTnkzL64hTbcH6tVw
8IFuFQRoT9YxxS9W4OkycBKJzyyXqYsY9GOv0mocJBtUFKPOmgsiUsqwe6lpeauDyF743Brz
d44FS5TOQmHFyMhFy/bBpvIcXcTwdecinedfUDZMzafrHeUFPFsOQzNAGHMxggM0MIIDMAIB
ATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg
SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNz
IDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQPOZ1
ckNS5Z3CqHJP0SwvXTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wMjA5MTcyMDU5NTBaMCMGCSqGSIb3DQEJBDEWBBTzXCjgKQ7Z
9LPnDcrFmCO5Gni/AzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYLKoZIhvcN
AQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEBBQAEgYByK+CDxt5VdiFAZ8pKSpGo
m93bb6mr+2juuiXO1Ol2UXzHdn/iPq6+6vIwYm73CKkzcAQ7d+0WufZYUPueHGLw2OIHliW4
KXj4A3I1amB50SYVBJPjESLc7yypjdX/sUgh0qnIcW4OL3u/9rfwkUhD94JCAVDtqbwJQnJM
1sb+oAAAAAAAAA==
--------------ms080509060801080503000602--



From owner-ietf-calendar@mail.imc.org  Tue Sep 17 17:54:52 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01887
	for <calsch-archive@lists.ietf.org>; Tue, 17 Sep 2002 17:54:52 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8HLblj09446
	for ietf-calendar-bks; Tue, 17 Sep 2002 14:37:47 -0700 (PDT)
Received: from office2.jigzaw.com (adsl-68-20-84-161.dsl.chcgil.ameritech.net [68.20.84.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HLbik09440
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 14:37:44 -0700 (PDT)
Received: from colatz ([10.0.0.10])
	by office2.jigzaw.com (8.9.3/8.9.3) with ESMTP id QAA28798
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 16:34:55 -0500
From: "Shannon J. Clark" <shannon@jigzaw.com>
To: <ietf-calendar@imc.org>
Subject: RE: Revised proposal
Date: Tue, 17 Sep 2002 16:38:17 -0500
Message-ID: <NEBBKFJICLIPPJJJBCFCEEBBDPAA.shannon@jigzaw.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
In-Reply-To: <3D8797C6.40001@Royer.com>
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Doug,

Quick note re one comment below:

Already multiple cell phone vendors (and networks) support cell phones with
camera attachments - which allow for the emailing of image files.

The next step of connecting that camera to other applications in the cell
phone (like calendars) seems very logical and easy to image (and useful).

For example - a meeting coordinator might email photos of a location to all
the attendees, or each attendee might attach a photo of themselves to aid
identification, or the item to be discussed at the meeting might be sent to
all attendees as an attachment.

As the lines between cell phones, PDAs, pocket computers, and laptops grow
increasingly meaningless I think we are wise to assume that current "small"
devices may already need to do tasks we mostly envisioned only "fat" clients
doing (like attaching files).

Shannon

-----Original Message-----
From: owner-ietf-calendar@mail.imc.org
[mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer
Sent: Tuesday, September 17, 2002 4:00 PM
To: ietf-calendar@imc.org
Subject: Re: Revised proposal

I disagree - the endpoint MUST do it OR send an error.
My CELL phone will not be exporting files - as an example,
even if it can do body part ATTACH and body part ALTREP.






From owner-ietf-calendar@mail.imc.org  Tue Sep 17 18:37:31 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02803
	for <calsch-archive@lists.ietf.org>; Tue, 17 Sep 2002 18:37:30 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8HMTOa13387
	for ietf-calendar-bks; Tue, 17 Sep 2002 15:29:24 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HMTNk13381
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 15:29:23 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8HMTPR2017630
	for <ietf-calendar@imc.org>; Tue, 17 Sep 2002 15:29:25 -0700
Message-ID: <3D87AA9A.9090406@Royer.com>
Date: Tue, 17 Sep 2002 16:20:10 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
References: <NEBBKFJICLIPPJJJBCFCEEBBDPAA.shannon@jigzaw.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020001070304000907090601"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms020001070304000907090601
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Shannon J. Clark wrote:
> Doug,
> 
> Quick note re one comment below:
> 
> Already multiple cell phone vendors (and networks) support cell phones with
> camera attachments - which allow for the emailing of image files.
> 
> The next step of connecting that camera to other applications in the cell
> phone (like calendars) seems very logical and easy to image (and useful).
> 
> For example - a meeting coordinator might email photos of a location to all
> the attendees, or each attendee might attach a photo of themselves to aid
> identification, or the item to be discussed at the meeting might be sent to
> all attendees as an attachment.
> 
> As the lines between cell phones, PDAs, pocket computers, and laptops grow
> increasingly meaningless I think we are wise to assume that current "small"
> devices may already need to do tasks we mostly envisioned only "fat" clients
> doing (like attaching files).

I think we agree, I am just saying that 'attachments' ARE possible.
However the cell phone is unlikely to be an HTTP or FTP server so that
external attachments can be downloaded from the cell phone. So I was saying
that if the other (non-cellphone) does not support multipart, then the cell
phone can not send attachments at all as it is not going to replace the body 
part with an ftp:<mycellphone#>/attachemnt-3 URI and tell the world it is an
FTP server. So a cell phone (or whatever), may elect to send and error if it
can not send attachments.


> Shannon
> 
> -----Original Message-----
> From: owner-ietf-calendar@mail.imc.org
> [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer
> Sent: Tuesday, September 17, 2002 4:00 PM
> To: ietf-calendar@imc.org
> Subject: Re: Revised proposal
> 
> I disagree - the endpoint MUST do it OR send an error.
> My CELL phone will not be exporting files - as an example,
> even if it can do body part ATTACH and body part ALTREP.
> 
> 
> 


--------------ms020001070304000907090601
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMoDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBJkwggQCoAMCAQICEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwMTIyMDAw
MDAwWhcNMDIxMDEyMjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALu5M8Oe
P9S38Qpp7q+co8hakIjYegcCXefm5J/+AjAPhn6PeB7CxHQObvRuMBxbHCmzoU2mGwxQGiUH
AqgvvcMYrw01LP4bx+/MysNrpID4+/+G/QiGSqqYKQR2BrArPOzeLe3epDLzM5WFc1BKSFS/
OW5MM2LQVLZuwJ6lTuHDAgMBAAGjggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEw
gZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24n
cyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjAR
BglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiAxODA2OWFmNjdiMzI3M2E1MDIz
NDAxZGMyNTcxZjc2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBACKuMzBrDvgZuvczrWqb4GfNo055My+u
IU23B+rVcPCBbhUEaE/WMcUvVuDpMnASic8sl6mLGPRjr9JqHCQbVBSjzpoLIlLKsHupaXmr
g8he+Nwa83eOBUuUzkJhxcjIRcv2wabyHF3E8HXnIp3nX1A2TM2n6x3lBTxbDkMzQBhzMIIE
mTCCBAKgAwIBAgIQPOZ1ckNS5Z3CqHJP0SwvXTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu
LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVh
bCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMjAxMjIwMDAwMDBaFw0w
MjEwMTIyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2Nh
cGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5k
b3VnQHJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu7kzw54/1LfxCmnu
r5yjyFqQiNh6BwJd5+bkn/4CMA+Gfo94HsLEdA5u9G4wHFscKbOhTaYbDFAaJQcCqC+9wxiv
DTUs/hvH78zKw2ukgPj7/4b9CIZKqpgpBHYGsCs87N4t7d6kMvMzlYVzUEpIVL85bkwzYtBU
tm7AnqVO4cMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZI
AYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMw
YgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBp
bmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG
+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDE4MDY5YWY2N2IzMjczYTUwMjM0MDFkYzI1
NzFmNzY0MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNz
MS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAIq4zMGsO+Bm69zOtapvgZ82jTnkzL64hTbcH6tVw
8IFuFQRoT9YxxS9W4OkycBKJzyyXqYsY9GOv0mocJBtUFKPOmgsiUsqwe6lpeauDyF743Brz
d44FS5TOQmHFyMhFy/bBpvIcXcTwdecinedfUDZMzafrHeUFPFsOQzNAGHMxggM0MIIDMAIB
ATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg
SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNz
IDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQPOZ1
ckNS5Z3CqHJP0SwvXTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wMjA5MTcyMjIwMTBaMCMGCSqGSIb3DQEJBDEWBBSfWGiaUxBV
sMOoK0jJFuQZgObC8jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYLKoZIhvcN
AQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEBBQAEgYARG0JD1JpWHecFrpPAO6bf
c4SLZ5Tqyk4SUS/f//Y45ooVexT/+IteALVj9xcfePV7eoFu8nCrjvIbytbc5ND8zk4NKXh4
vROFfT9XAZmTJ4JE7d9h8SRgEQ5XhkspHWheO4FDhqmuREDARP/8F3Amc2BEpIabbNLQEGai
U7pPDQAAAAAAAA==
--------------ms020001070304000907090601--



From owner-ietf-calendar@mail.imc.org  Wed Sep 18 04:11:22 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05553
	for <calsch-archive@lists.ietf.org>; Wed, 18 Sep 2002 04:11:21 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8I86H223214
	for ietf-calendar-bks; Wed, 18 Sep 2002 01:06:17 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8I86Fk23205
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 01:06:16 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id CB470155BE; Wed, 18 Sep 2002 10:06:14 +0200 (CEST)
Date: Wed, 18 Sep 2002 10:06:14 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
Message-ID: <20020918080614.GG39963@inet.it>
References: <3D875DB4.80407@Royer.com> <20020917182534.GF39963@inet.it> <3D8797C6.40001@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D8797C6.40001@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Tue, Sep 17, 2002 at 02:59:50PM -0600, Doug Royer wrote:
> 
> >>support multipart MUST be able to receive the following as one
> >>command reply:
> >>
> >>   (1) One MIME object of type text/calendar. (Not multipart)
> >>       And each text/calendar must contain one or more iCalendar objects.
> >>       All with the same METHOD.
> >>
> >>   (2) Multiple MIME objects each of type text/calendar (Not multipart)
> >>       And each text/calendar must contain one or more iCalendar objects
> >>       of the same METHOD.
> >
> >
> >Do you mean (2) can be used with one text/calendar object per ANS in
> >a ANS/NUL reply? If so, I agree.
> 
> Currently I have left BEEP out of it, I mean the the CS or CUA
> can send one or more text/calendar MIME objects, each with a unique
> METHOD. And each can contain multiple iCalendar objects.

I don't see how BEEP can be left out without confusing the matter...
Anyawy, this is ok with me as long as it means one text/calendar per
[whatever underlying transport protocol] "message". This is not ok
if it means more than one text/calendar per message, as it means
we would need to tell where one text/calendar object ends and a new
one begins, i.e. basically reinvent MIME.

> >>If a CUA or CS does not support multipart, then all ALTREP
> >>values must be stored external to the text/calendar object
> >>and can not be transmitted using CAP.
> >>
> >>I think it is out of scope for CAP to specify how.
> >
> >
> >I agree it's out of scopr to specify how, but it's in scope to state
> >this must be done.
> 
> I disagree - the endpoint MUST do it OR send an error.
> My CELL phone will not be exporting files - as an example,
> even if it can do body part ATTACH and body part ALTREP.

You've taken my answer out of context. I answered to a comment
you made on my original statement of a FACT - if an endpoint has
limited capability, it MUST do something about it, including
responding with any relevant error. So it seems we agree.

In your example (a mobile phone which can do multipart but connects
to a server that can't) it would still be possible to inline the
data or store it to an external server. If it can reach the CS,
I see no reason why it would not be able to reach an IMAP server,
and IMAP protocol would probably be supported on that phone anyway.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep 18 04:19:56 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05670
	for <calsch-archive@lists.ietf.org>; Wed, 18 Sep 2002 04:19:55 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8I8CjU25070
	for ietf-calendar-bks; Wed, 18 Sep 2002 01:12:45 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8I8Cik25059
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 01:12:44 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id C15D2155BE; Wed, 18 Sep 2002 10:12:43 +0200 (CEST)
Date: Wed, 18 Sep 2002 10:12:43 +0200
From: Andrea Campi <a.campi@inet.it>
To: "Shannon J. Clark" <shannon@jigzaw.com>
Cc: ietf-calendar@imc.org
Subject: Re: Revised proposal
Message-ID: <20020918081243.GH39963@inet.it>
References: <3D8797C6.40001@Royer.com> <NEBBKFJICLIPPJJJBCFCEEBBDPAA.shannon@jigzaw.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <NEBBKFJICLIPPJJJBCFCEEBBDPAA.shannon@jigzaw.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Tue, Sep 17, 2002 at 04:38:17PM -0500, Shannon J. Clark wrote:
> As the lines between cell phones, PDAs, pocket computers, and laptops grow
> increasingly meaningless I think we are wise to assume that current "small"
> devices may already need to do tasks we mostly envisioned only "fat" clients
> doing (like attaching files).

I don't know how things work in the US, but here in Europe odds are
all parts are (at least partly) under control of a service provider.
If the service provider is going to use a limited CS, it's very
reasonable to expect it would also have an external store (be it
FTP, HTTP, WebDAV, IMAP, etc) _AND_ the cell phone would know how
to use it to its advantage. This is useful not only to a CUA -
think automatic slideshow of the pictures you take, etc...

So I guess I agree with you, but I think "small" devices will still
need external assistance to work optimally.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep 18 09:48:18 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13094
	for <calsch-archive@lists.ietf.org>; Wed, 18 Sep 2002 09:48:17 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8IDUcl21257
	for ietf-calendar-bks; Wed, 18 Sep 2002 06:30:38 -0700 (PDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IDUbk21253
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 06:30:37 -0700 (PDT)
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IDUX710013
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 06:30:33 -0700 (PDT)
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IDUXp10004
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 06:30:33 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8IDUVr11556
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 07:30:32 -0600 (MDT)
Message-ID: <3D887FF6.F121375A@oracle.com>
Date: Wed, 18 Sep 2002 09:30:30 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
References: <3D875DB4.80407@Royer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Doug Royer wrote:
> 

...

>  >  2 Multipart negotiation
>  >
>  > A CUA and a CS SHOULD negotiate the level of multipart support.
> 

> How about:
> 
>    A CS MUST send the MULTIPART capability and a CUA MUST send
>    the MULTIPART capability when the CUA supports sending CAPABILITY.
> 
>    If the CUA does not support CAPABILITY, the CS MUST assume that
>    the CUA does not support any multipart.
> 
>    The value of the MULTIPART capability may be empty meaning that
>    no multipart is supported by that endpoint.
> 

How about making sending CAPABILITY a MUST for both the CS and CUA?
It can make things simpler, and it should not add too much complexity
to and burden on the CUA.

George


From owner-ietf-calendar@mail.imc.org  Wed Sep 18 13:52:14 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23550
	for <calsch-archive@lists.ietf.org>; Wed, 18 Sep 2002 13:52:14 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8IHXRX04136
	for ietf-calendar-bks; Wed, 18 Sep 2002 10:33:27 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IHXPk04132
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 10:33:26 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8IHXQR2025554
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 10:33:27 -0700
Message-ID: <3D88B6B3.7090903@Royer.com>
Date: Wed, 18 Sep 2002 11:24:03 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
References: <3D875DB4.80407@Royer.com> <3D887FF6.F121375A@oracle.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070708000307090604060704"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms070708000307090604060704
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



George Babics wrote:
> 
> Doug Royer wrote:
> 
> 
> ...
> 
> 
>> >  2 Multipart negotiation
>> >
>> > A CUA and a CS SHOULD negotiate the level of multipart support.
>>
> 
> 
>>How about:
>>
>>   A CS MUST send the MULTIPART capability and a CUA MUST send
>>   the MULTIPART capability when the CUA supports sending CAPABILITY.
>>
>>   If the CUA does not support CAPABILITY, the CS MUST assume that
>>   the CUA does not support any multipart.
>>
>>   The value of the MULTIPART capability may be empty meaning that
>>   no multipart is supported by that endpoint.
>>
> 
> 
> How about making sending CAPABILITY a MUST for both the CS and CUA?
> It can make things simpler, and it should not add too much complexity
> to and burden on the CUA.

I have no problem with that, I thought others objected.

If there are no objections, I'll change '9.3' to be:

9.3 GET-CAPABILITY Command

    CMD: GET-CAPABILITY

    Purpose: The GET-CAPABILITY command returns the capabilities of the
    other end of the session.

    A CUA MUST send a GET-CAPABILITY command to a CS. The CUA MUST NOT
    send any other commands until it has the GET-CAPABILITY reply from
    the CS.

    The CS MUST send a GET-CAPABILITY command to any CUA. The CS MUST NOT
    send any other commands until it has the GET-CAPABILITY reply from
    the CUA.


WAS:


9.3 GET-CAPABILITY Command

    CMD: GET-CAPABILITY

    Purpose: The GET-CAPABILITY command returns the capabilities of the
    other end of the session.

    A CUA MAY send a GET-CAPABILITY command to a CS.  The GET-CAPABILITY
    command MUST BE implemented by all CSs.

    The CS MAY send a GET-CAPABILITY command to any CUA.  The GET-
    CAPABILITY command MAY be implemented by a CUA.







--------------ms070708000307090604060704
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMoDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBJkwggQCoAMCAQICEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwMTIyMDAw
MDAwWhcNMDIxMDEyMjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALu5M8Oe
P9S38Qpp7q+co8hakIjYegcCXefm5J/+AjAPhn6PeB7CxHQObvRuMBxbHCmzoU2mGwxQGiUH
AqgvvcMYrw01LP4bx+/MysNrpID4+/+G/QiGSqqYKQR2BrArPOzeLe3epDLzM5WFc1BKSFS/
OW5MM2LQVLZuwJ6lTuHDAgMBAAGjggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEw
gZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24n
cyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjAR
BglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiAxODA2OWFmNjdiMzI3M2E1MDIz
NDAxZGMyNTcxZjc2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBACKuMzBrDvgZuvczrWqb4GfNo055My+u
IU23B+rVcPCBbhUEaE/WMcUvVuDpMnASic8sl6mLGPRjr9JqHCQbVBSjzpoLIlLKsHupaXmr
g8he+Nwa83eOBUuUzkJhxcjIRcv2wabyHF3E8HXnIp3nX1A2TM2n6x3lBTxbDkMzQBhzMIIE
mTCCBAKgAwIBAgIQPOZ1ckNS5Z3CqHJP0SwvXTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu
LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVh
bCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMjAxMjIwMDAwMDBaFw0w
MjEwMTIyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2Nh
cGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5k
b3VnQHJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu7kzw54/1LfxCmnu
r5yjyFqQiNh6BwJd5+bkn/4CMA+Gfo94HsLEdA5u9G4wHFscKbOhTaYbDFAaJQcCqC+9wxiv
DTUs/hvH78zKw2ukgPj7/4b9CIZKqpgpBHYGsCs87N4t7d6kMvMzlYVzUEpIVL85bkwzYtBU
tm7AnqVO4cMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZI
AYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMw
YgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBp
bmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG
+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDE4MDY5YWY2N2IzMjczYTUwMjM0MDFkYzI1
NzFmNzY0MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNz
MS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAIq4zMGsO+Bm69zOtapvgZ82jTnkzL64hTbcH6tVw
8IFuFQRoT9YxxS9W4OkycBKJzyyXqYsY9GOv0mocJBtUFKPOmgsiUsqwe6lpeauDyF743Brz
d44FS5TOQmHFyMhFy/bBpvIcXcTwdecinedfUDZMzafrHeUFPFsOQzNAGHMxggM0MIIDMAIB
ATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg
SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNz
IDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQPOZ1
ckNS5Z3CqHJP0SwvXTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wMjA5MTgxNzI0MDNaMCMGCSqGSIb3DQEJBDEWBBRly3VFbgGJ
I/6iuhPMM/lNvsUDNzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYLKoZIhvcN
AQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEBBQAEgYCV86W19JD60XgcqK00PJXA
07vQ8DIf/fmXh51HMpg5TYtG54a9oBCSRHEsq3piVjcJeBFr+m5rogUSnyt0l3+Z+E8nAe1r
gpbNzAqg9Cl2KjVbY54yGHOsx5C0i4yKoQzzsYx77RVsytQM0XaXaGdmMi3mQgm84k5pPnck
AwYgHAAAAAAAAA==
--------------ms070708000307090604060704--



From owner-ietf-calendar@mail.imc.org  Wed Sep 18 14:28:33 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24780
	for <calsch-archive@lists.ietf.org>; Wed, 18 Sep 2002 14:28:32 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8IIDxb06620
	for ietf-calendar-bks; Wed, 18 Sep 2002 11:13:59 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IIDwk06616
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 11:13:59 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id 6802C155C4; Wed, 18 Sep 2002 20:13:59 +0200 (CEST)
Date: Wed, 18 Sep 2002 20:13:59 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
Message-ID: <20020918181359.GR39963@inet.it>
References: <3D875DB4.80407@Royer.com> <3D887FF6.F121375A@oracle.com> <3D88B6B3.7090903@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D88B6B3.7090903@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Wed, Sep 18, 2002 at 11:24:03AM -0600, Doug Royer wrote:
> >How about making sending CAPABILITY a MUST for both the CS and CUA?
> >It can make things simpler, and it should not add too much complexity
> >to and burden on the CUA.
> 
> I have no problem with that, I thought others objected.
> 
> If there are no objections, I'll change '9.3' to be:
> 
> 9.3 GET-CAPABILITY Command
> 
>    CMD: GET-CAPABILITY
> 
>    Purpose: The GET-CAPABILITY command returns the capabilities of the
>    other end of the session.
> 
>    A CUA MUST send a GET-CAPABILITY command to a CS. The CUA MUST NOT
>    send any other commands until it has the GET-CAPABILITY reply from
>    the CS.
> 
>    The CS MUST send a GET-CAPABILITY command to any CUA. The CS MUST NOT
>    send any other commands until it has the GET-CAPABILITY reply from
>    the CUA.

I agree.

I would add:

	The GET-CAPABILITY command MAY be implemented by a CUA.
	If it's not, a CS MUST assume all capabilities take the default
	values.



-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep 18 17:11:25 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00194
	for <calsch-archive@lists.ietf.org>; Wed, 18 Sep 2002 17:11:25 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8IL6Dj16192
	for ietf-calendar-bks; Wed, 18 Sep 2002 14:06:13 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IL6Ck16188
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 14:06:12 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8IL6ER2027043
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 14:06:14 -0700
Message-ID: <3D88E893.80804@Royer.com>
Date: Wed, 18 Sep 2002 14:56:51 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
References: <3D875DB4.80407@Royer.com> <3D887FF6.F121375A@oracle.com> <3D88B6B3.7090903@Royer.com> <20020918181359.GR39963@inet.it>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060906080407090104030800"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms060906080407090104030800
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Andrea,

If you read George's post, you will see that he thought it should
be a MUST (not a MAY), so my proposal (that you responded to) agreed
with him.

Do you object to George's proposal that a CUA MUST ask GET-CAPABILITY?
Or are you saying you can go with a MUST or a MAY and that
is is not that important to you?

Andrea Campi wrote:
> On Wed, Sep 18, 2002 at 11:24:03AM -0600, Doug Royer wrote:
> 
>>>How about making sending CAPABILITY a MUST for both the CS and CUA?
>>>It can make things simpler, and it should not add too much complexity
>>>to and burden on the CUA.
>>
>>I have no problem with that, I thought others objected.
>>
>>If there are no objections, I'll change '9.3' to be:
>>
>>9.3 GET-CAPABILITY Command
>>
>>   CMD: GET-CAPABILITY
>>
>>   Purpose: The GET-CAPABILITY command returns the capabilities of the
>>   other end of the session.
>>
>>   A CUA MUST send a GET-CAPABILITY command to a CS. The CUA MUST NOT
>>   send any other commands until it has the GET-CAPABILITY reply from
>>   the CS.
>>
>>   The CS MUST send a GET-CAPABILITY command to any CUA. The CS MUST NOT
>>   send any other commands until it has the GET-CAPABILITY reply from
>>   the CUA.
> 
> 
> I agree.
> 
> I would add:
> 
> 	The GET-CAPABILITY command MAY be implemented by a CUA.
> 	If it's not, a CS MUST assume all capabilities take the default
> 	values.
> 
> 
> 


--------------ms060906080407090104030800
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMoDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBJkwggQCoAMCAQICEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwMTIyMDAw
MDAwWhcNMDIxMDEyMjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALu5M8Oe
P9S38Qpp7q+co8hakIjYegcCXefm5J/+AjAPhn6PeB7CxHQObvRuMBxbHCmzoU2mGwxQGiUH
AqgvvcMYrw01LP4bx+/MysNrpID4+/+G/QiGSqqYKQR2BrArPOzeLe3epDLzM5WFc1BKSFS/
OW5MM2LQVLZuwJ6lTuHDAgMBAAGjggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEw
gZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24n
cyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjAR
BglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiAxODA2OWFmNjdiMzI3M2E1MDIz
NDAxZGMyNTcxZjc2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBACKuMzBrDvgZuvczrWqb4GfNo055My+u
IU23B+rVcPCBbhUEaE/WMcUvVuDpMnASic8sl6mLGPRjr9JqHCQbVBSjzpoLIlLKsHupaXmr
g8he+Nwa83eOBUuUzkJhxcjIRcv2wabyHF3E8HXnIp3nX1A2TM2n6x3lBTxbDkMzQBhzMIIE
mTCCBAKgAwIBAgIQPOZ1ckNS5Z3CqHJP0SwvXTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu
LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVh
bCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMjAxMjIwMDAwMDBaFw0w
MjEwMTIyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2Nh
cGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApEb3VnIFJveWVyMR0wGwYJKoZIhvcNAQkBFg5k
b3VnQHJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu7kzw54/1LfxCmnu
r5yjyFqQiNh6BwJd5+bkn/4CMA+Gfo94HsLEdA5u9G4wHFscKbOhTaYbDFAaJQcCqC+9wxiv
DTUs/hvH78zKw2ukgPj7/4b9CIZKqpgpBHYGsCs87N4t7d6kMvMzlYVzUEpIVL85bkwzYtBU
tm7AnqVO4cMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZI
AYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMw
YgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBp
bmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG
+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDE4MDY5YWY2N2IzMjczYTUwMjM0MDFkYzI1
NzFmNzY0MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNz
MS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAIq4zMGsO+Bm69zOtapvgZ82jTnkzL64hTbcH6tVw
8IFuFQRoT9YxxS9W4OkycBKJzyyXqYsY9GOv0mocJBtUFKPOmgsiUsqwe6lpeauDyF743Brz
d44FS5TOQmHFyMhFy/bBpvIcXcTwdecinedfUDZMzafrHeUFPFsOQzNAGHMxggM0MIIDMAIB
ATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg
SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNz
IDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQPOZ1
ckNS5Z3CqHJP0SwvXTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wMjA5MTgyMDU2NTFaMCMGCSqGSIb3DQEJBDEWBBRfdBlhs8yK
Cc7rpG4JlDos7A7B4zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYLKoZIhvcN
AQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQCEDzmdXJDUuWdwqhyT9EsL10wDQYJKoZIhvcNAQEBBQAEgYCpbnm7QF3zu+xAag++nAQ4
4GQtFXfkEe8+DZNGAmNb9qxWoQwnPxHDyy3Xku0hVpdBFsXzxyJYg0M3mnzmNHcndhIeNT5t
Z2YBEJ+iLdH8CrTgFQAYKNkzFqzDd1J/AQY/CWKPDGnjg8xVkId1CDUa2zrRu9AkMUTxEkQd
0GUVCQAAAAAAAA==
--------------ms060906080407090104030800--



From owner-ietf-calendar@mail.imc.org  Wed Sep 18 18:08:20 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01803
	for <calsch-archive@lists.ietf.org>; Wed, 18 Sep 2002 18:08:19 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8ILxWL17889
	for ietf-calendar-bks; Wed, 18 Sep 2002 14:59:32 -0700 (PDT)
Received: from acampi.inet.it ([213.92.1.165])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ILxVk17884
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 14:59:31 -0700 (PDT)
Received: by acampi.inet.it (Postfix, from userid 210)
	id B6D01155C4; Wed, 18 Sep 2002 23:59:33 +0200 (CEST)
Date: Wed, 18 Sep 2002 23:59:33 +0200
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
Message-ID: <20020918215933.GD35162@inet.it>
References: <3D875DB4.80407@Royer.com> <3D887FF6.F121375A@oracle.com> <3D88B6B3.7090903@Royer.com> <20020918181359.GR39963@inet.it> <3D88E893.80804@Royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D88E893.80804@Royer.com>
Organization: I.NET S.p.A.
User-Agent: Mutt/1.5.1i
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Wed, Sep 18, 2002 at 02:56:51PM -0600, Doug Royer wrote:
> Andrea,
> 
> If you read George's post, you will see that he thought it should
> be a MUST (not a MAY), so my proposal (that you responded to) agreed
> with him.
> 
> Do you object to George's proposal that a CUA MUST ask GET-CAPABILITY?
> Or are you saying you can go with a MUST or a MAY and that
> is is not that important to you?

I agree with both of you that a CUA MUST send the GET-CAPABILITY.
I agree with both of you that a CS MUST send the GET-CAPABILITY.
Everybody agrees a CS MUST implement and respond to the GET-CAPABILITY.

I was merely suggesting (but I would not fight over this if somebody
opposed it) that we could keep GET-CAPABILITY implementation and
response optional, as in the existent text. So a CS would still send
it and get back a REQUEST-STATUS:9.0;Unimplemented. In this case the
CS should simply assume the CUA uses the defaults for all properties -
we just have to make sure the defaults are reasonable, of course.

This would slightly simplify really naive implementations of CUAs
(say, a simple CGI which offers a read only view of a public agenda),
by allowing them to implement no command at all.

Bye,
	andrea

> 
> >I agree.
> >
> >I would add:
> >
> >	The GET-CAPABILITY command MAY be implemented by a CUA.
> >	If it's not, a CS MUST assume all capabilities take the default
> >	values.
> 



-- 
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy


From owner-ietf-calendar@mail.imc.org  Wed Sep 18 19:57:42 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04082
	for <calsch-archive@lists.ietf.org>; Wed, 18 Sep 2002 19:57:42 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8INfJ122039
	for ietf-calendar-bks; Wed, 18 Sep 2002 16:41:19 -0700 (PDT)
Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8INfHk22025
	for <ietf-calendar@imc.org>; Wed, 18 Sep 2002 16:41:18 -0700 (PDT)
Received: from cube.local. (host50-59.pool80206.interbusiness.it [80.206.59.50])
	by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g8INfI5f015332
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 01:41:18 +0200
Date: Thu, 19 Sep 2002 01:23:00 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v543)
Subject: iMIP
From: Andrea Campi <a.campi@inet.it>
To: ieft-calendar@imc.org
Message-Id: <1F712551-CB60-11D6-AABB-003065A8EEFC@inet.it>
X-Mailer: Apple Mail (2.543)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Hi all,

more than once we have discussed whether full iMIP support is required 
for CAP compliance; in particular,  this has to do with multipart 
support, as iMIP compliance implies multipart support.

This is my proposal: add an IMIP-VERSION property to GET-CAPABILITY (by 
the way, I noticed a typo in ITIP-VERSION, 2447 should be 2446):


       IMIP-VERSION     1     Version(s) of IMIP, comma separated list. 
To specify RFC-2447 support the list MUST include at least 2447. 
Alternatively, in can be set to NONE.
If an endpoint specifies RFC2447 it MUST implement all of RFC2447, 
including support for multipart, and respect any restrictions. Notably, 
it MUST use separate text/calendar body parts for iCalendar objects 
with different methods. The exact MULTIPART support MUST still be 
specified using the MULTIPART property. [note: I'm open for discussion 
on this last sentence]
If an endpoint specifies NONE it is not bound by any requirement in 
RFC2447. In particular, it can send multiple iCalendar objects with 
different METHODs inside one text/calendar body part. Any MULTIPART 
support SHOULD be specified using the MULTIPART property, or MULTIPART 
can be left out if the endpoint can't use MULTIPART.



I think this proposal allows for maximum freedom of implementation 
while still being precise enough. The only downside I see is that an 
iMIP compliant endpoint needs to handle non-iMIP compliant contents. 
But this simply means not enforcing a restriction, so I guess it's not 
a problem.


What do you think?


Bye,
	Andrea



From owner-ietf-calendar@mail.imc.org  Thu Sep 19 12:19:45 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12690
	for <calsch-archive@lists.ietf.org>; Thu, 19 Sep 2002 12:19:45 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8JG5rS12022
	for ietf-calendar-bks; Thu, 19 Sep 2002 09:05:53 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JG5pk12015
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 09:05:51 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8JG5qR2002604
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 09:05:52 -0700
Message-ID: <3D89F3A5.1040202@Royer.com>
Date: Thu, 19 Sep 2002 09:56:21 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
References: <3D875DB4.80407@Royer.com> <3D887FF6.F121375A@oracle.com> <3D88B6B3.7090903@Royer.com> <20020918181359.GR39963@inet.it> <3D88E893.80804@Royer.com> <20020918215933.GD35162@inet.it>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060306060408020205080309"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms060306060408020205080309
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


I believe that you are stating that CAP should not change.
What you are suggesting now is what the draft currently states.

Does anyone else agree with George that both the CS and CUA
MUST support GET-CAPABILITY? (I could go with MAY or MUST).

-Doug


Andrea Campi wrote:
> On Wed, Sep 18, 2002 at 02:56:51PM -0600, Doug Royer wrote:
> 
>>Andrea,
>>
>>If you read George's post, you will see that he thought it should
>>be a MUST (not a MAY), so my proposal (that you responded to) agreed
>>with him.
>>
>>Do you object to George's proposal that a CUA MUST ask GET-CAPABILITY?
>>Or are you saying you can go with a MUST or a MAY and that
>>is is not that important to you?
> 
> 
> I agree with both of you that a CUA MUST send the GET-CAPABILITY.
> I agree with both of you that a CS MUST send the GET-CAPABILITY.
> Everybody agrees a CS MUST implement and respond to the GET-CAPABILITY.
> 
> I was merely suggesting (but I would not fight over this if somebody
> opposed it) that we could keep GET-CAPABILITY implementation and
> response optional, as in the existent text. So a CS would still send
> it and get back a REQUEST-STATUS:9.0;Unimplemented. In this case the
> CS should simply assume the CUA uses the defaults for all properties -
> we just have to make sure the defaults are reasonable, of course.
> 
> This would slightly simplify really naive implementations of CUAs
> (say, a simple CGI which offers a read only view of a public agenda),
> by allowing them to implement no command at all.
> 
> Bye,
> 	andrea
> 
> 
>>>I agree.
>>>
>>>I would add:
>>>
>>>	The GET-CAPABILITY command MAY be implemented by a CUA.
>>>	If it's not, a CS MUST assume all capabilities take the default
>>>	values.
>>
> 
> 
> 


--------------ms060306060408020205080309
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkxOTE1NTYyMVowIwYJKoZIhvcNAQkEMRYEFK0NT+QH
NBE4hBzSfNpJymQsnoRyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCG2ZQYmALTZcs8LL+P
UHpqtt08OH6Ld9EH8J7+zLnsTw4xfsHAG5jvEqTyIiX/wSH3zdH8pIxWXDQYppzE3R7BmzOU
lIL/+4A0BsSnOIyVLsAIOlo+5Ncouw6ZS4ZPxXpY2G9rYRu/Cw7n1vWg3u0ydgrxNi014pDX
iNPevYgz5ebdj/ZRQ/WLsPFthqvCP29azamKbGeoo2QAwGdhsWPiFggqtuNwNFp2TE99q+in
Hn4kWhtydVost3EULQLBUJKgclCqybTyNTXKTWZGOKun5EvRK012K/Bg9a7KNZd+6NisfGcu
oTzhAWSf/CEYi6GS+eb6EYH7rVT0sNPXop1ZAAAAAAAA
--------------ms060306060408020205080309--



From owner-ietf-calendar@mail.imc.org  Thu Sep 19 12:22:20 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12799
	for <calsch-archive@lists.ietf.org>; Thu, 19 Sep 2002 12:22:19 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8JG8KB12380
	for ietf-calendar-bks; Thu, 19 Sep 2002 09:08:20 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JG8Ik12374
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 09:08:18 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8JG8JR2002623
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 09:08:19 -0700
Message-ID: <3D89F438.8010803@Royer.com>
Date: Thu, 19 Sep 2002 09:58:48 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ieft-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: iMIP
References: <1F712551-CB60-11D6-AABB-003065A8EEFC@inet.it>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090508090803070508090302"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms090508090803070508090302
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Andrea Campi wrote:

> ... I noticed a typo in ITIP-VERSION, 2447 should be 2446): ...

Thanks - I just edited in the fix.


--------------ms090508090803070508090302
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkxOTE1NTg0OFowIwYJKoZIhvcNAQkEMRYEFDjyuLIg
v82qsaa1qLX7wF4JS2KbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAI3ZAVWZD6U8ZrhdgH
TuIy+Q46R4NV2kLZS8DojVRcklFQHLRpvtyGrqd5eRI0Tc0DkiDvVIo/0jkCYTCbhXCME0G8
krqL8RZeNtByHfmhrKz1ncoYWVpBnhJZ/BFTOs64QfhOx0SkO5JCtkmb8w/2TQIXQXm89Pc8
fY0okzkWJpF0IVaERGmcV/RBlIt+xI1G24BjrtRiziQqB4Y0mkJohyBMW3X9MrHy60mdfadu
kwu1b6SPRKXzuwqbhT1d1M3U9A2DDYPMczXg/iJjdQpyDwQsglDnF+DbVExBmn5wt+2TJfpM
v7SxxAO914folik/Rvd+NGEztHhF9GlcsYdOAAAAAAAA
--------------ms090508090803070508090302--



From owner-ietf-calendar@mail.imc.org  Thu Sep 19 12:55:02 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14048
	for <calsch-archive@lists.ietf.org>; Thu, 19 Sep 2002 12:55:01 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8JGaX814331
	for ietf-calendar-bks; Thu, 19 Sep 2002 09:36:33 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JGaVk14327
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 09:36:31 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8JGaWR2002818
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 09:36:32 -0700
Message-ID: <3D89FAD5.4030704@Royer.com>
Date: Thu, 19 Sep 2002 10:27:01 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: iMIP
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030105010502060303010506"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms030105010502060303010506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[may be a resend - I hit send before I was done typing ...]

 >... IMIP-VERSION     1     Version(s) of IMIP, comma separated list. To
 > specify RFC-2447 support the list MUST include at least 2447. Alternatively,
 > in can be set to NONE.
 >
 > If an endpoint specifies RFC2447 it MUST implement all of RFC2447, including
 > support for multipart, and respect any restrictions.

I do not think that multipart is a MUST in iMIP. We would still need something
like a MULTIPART property in GET-CAPABILITY in order to determine if the other
endpoint supported multipart. That was one of the points that Bruce has
been pointing out.

iMIP requires the 'From:' and other 822 headers. I don't think
we want to add that to CAP. Do we care?

--------------ms030105010502060303010506
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkxOTE2MjcwMVowIwYJKoZIhvcNAQkEMRYEFLkcl5eN
xQoU6v52ScdZtWs/QzgwMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAxGcb6zbAM/+0c4scI
C5Qx+gYXMPp5kqNcIs9y1G7lLpgC5Z+/Y/TkKJYeAHsw2V3VIbmR4kclMBpk+bewg19V/lS5
tLucNHnwdSzXh/Y7hYs9pEi/VUvVZdQdcXed3I9PUrtdbuQYZVzBfzP1WJAm7pdPIwatRu+D
0TH/StgjGS1gkPrJbkAyTjL80a2rqXSKnwrk5Y9f1+fvo3jn5xJOGQDQ0SD5twFaxLAl5UbB
QyQETSeQtRlClLorTzcf0i7h2Y2TMpvLYhratHUd9z2SOaBz5J+W8NliXpVn8Oc1eTgXkkqc
eAtCoWJBnjWdYl/kgGqhcvcN+u3Zq+eFdPmMAAAAAAAA
--------------ms030105010502060303010506--



From owner-ietf-calendar@mail.imc.org  Thu Sep 19 14:53:39 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18463
	for <calsch-archive@lists.ietf.org>; Thu, 19 Sep 2002 14:53:39 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8JIiKx20509
	for ietf-calendar-bks; Thu, 19 Sep 2002 11:44:20 -0700 (PDT)
Received: from maya.ngi.it (maya.ngi.it [194.177.103.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JIiJk20504
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 11:44:19 -0700 (PDT)
Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50])
	by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g8JIiIUo008510
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 20:44:20 +0200
Date: Thu, 19 Sep 2002 20:38:34 +0200
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ieft-calendar@imc.org
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Re: iMIP
From: Andrea Campi <a.campi@inet.it>
To: George Babics <george.babics@oracle.com>
Content-Transfer-Encoding: 7bit
Message-Id: <CBDA4FCC-CBFF-11D6-8F78-003065A8EEFC@inet.it>
X-Mailer: Apple Mail (2.546)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Hi all,

>> more than once we have discussed whether full iMIP support is required
>> for CAP compliance; in particular,  this has to do with multipart
>> support, as iMIP compliance implies multipart support.
>
>   I am not sure what you mean by iMIP support. Do you mean the CUA
> sending/storing iMIP messages on the CS?

I mean supporting at least all MUST; this in turn means a CUA would be 
able to store an iMIP message on the CS as is. This also means a CUA 
would be able to take the answer to any query and use it as the body of 
an email.
But see below.

>> This is my proposal: add an IMIP-VERSION property to GET-CAPABILITY 
>> (by
>> the way, I noticed a typo in ITIP-VERSION, 2447 should be 2446):
>>
>>        IMIP-VERSION     1     Version(s) of IMIP, comma separated 
>> list.
>> To specify RFC-2447 support the list MUST include at least 2447.
>> Alternatively, in can be set to NONE.
>> If an endpoint specifies RFC2447 it MUST implement all of RFC2447,
>
>   Does it need to implement all of RFC 2447 or simply all the MUSTs
> in RFC 2447?

The MUST would suffice I guess (this is for the wg to decide).

In fact, I came up with this proposal to address the exact opposite: a 
CS or a CUA which don't advertise RFC2447 would not be bound by any 
restriction in that RFC, only 244[56].

Bye,
	Andrea



From owner-ietf-calendar@mail.imc.org  Thu Sep 19 14:55:15 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18570
	for <calsch-archive@lists.ietf.org>; Thu, 19 Sep 2002 14:55:14 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8JIi6j20475
	for ietf-calendar-bks; Thu, 19 Sep 2002 11:44:06 -0700 (PDT)
Received: from maya.ngi.it (maya.ngi.it [194.177.103.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JIi4k20469
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 11:44:04 -0700 (PDT)
Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50])
	by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g8JIi4Uo008486
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 20:44:05 +0200
Date: Thu, 19 Sep 2002 20:44:01 +0200
Subject: Re: iMIP
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3D89FAD5.4030704@Royer.com>
Message-Id: <C393827E-CBFF-11D6-8F78-003065A8EEFC@inet.it>
X-Mailer: Apple Mail (2.546)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



On Thursday, September 19, 2002, at 06:27 PM, Doug Royer wrote:

> [may be a resend - I hit send before I was done typing ...]
>
> >... IMIP-VERSION     1     Version(s) of IMIP, comma separated list. 
> To
> > specify RFC-2447 support the list MUST include at least 2447. 
> Alternatively,
> > in can be set to NONE.
> >
> > If an endpoint specifies RFC2447 it MUST implement all of RFC2447, 
> including
> > support for multipart, and respect any restrictions.
>
> I do not think that multipart is a MUST in iMIP. We would still need 
> something

I'm not sure, either.

> like a MULTIPART property in GET-CAPABILITY in order to determine if 
> the other
> endpoint supported multipart. That was one of the points that Bruce has
> been pointing out.

Yes, and I wrote that in my proposal, you cut it in your response.

> iMIP requires the 'From:' and other 822 headers. I don't think
> we want to add that to CAP. Do we care?

No, of course not. Headers are not part of the payload. Only the 
payload of CAP and iMIP messages would need to be compatible.

Sorry, I didn't understand if you dislike the idea as a whole or if you 
only find the wording unclear or misleading. If the latter, I could 
rewrite the proposal to address your objections, no problem.

Bye,
	Andrea



From owner-ietf-calendar@mail.imc.org  Thu Sep 19 14:55:41 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18600
	for <calsch-archive@lists.ietf.org>; Thu, 19 Sep 2002 14:55:41 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8JIn3h21050
	for ietf-calendar-bks; Thu, 19 Sep 2002 11:49:03 -0700 (PDT)
Received: from maya.ngi.it (maya.ngi.it [194.177.103.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JIn2k21043
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 11:49:02 -0700 (PDT)
Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50])
	by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g8JIn2Uo008999
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 20:49:03 +0200
Date: Thu, 19 Sep 2002 20:48:59 +0200
Subject: Re: Revised proposal
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3D89F3A5.1040202@Royer.com>
Message-Id: <7558294D-CC00-11D6-8F78-003065A8EEFC@inet.it>
X-Mailer: Apple Mail (2.546)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



On Thursday, September 19, 2002, at 05:56 PM, Doug Royer wrote:

>
> I believe that you are stating that CAP should not change.
> What you are suggesting now is what the draft currently states.
>
> Does anyone else agree with George that both the CS and CUA
> MUST support GET-CAPABILITY? (I could go with MAY or MUST).

Sorry there's a misunderstanding somewhere.
I read George proposal (and I strongly agree on that) as changing CAP 
to say both the CS and CUA MUST send GET-CAPABILITY as the first 
command in a session.
I thought this was what you are agreeing to?


I simply added: we may want to leave: the CS MUST support 
GET-CAPABILITY, the CUA MAY.

Is this clearer?



>
> -Doug
>
>
> Andrea Campi wrote:
>> On Wed, Sep 18, 2002 at 02:56:51PM -0600, Doug Royer wrote:
>>> Andrea,
>>>
>>> If you read George's post, you will see that he thought it should
>>> be a MUST (not a MAY), so my proposal (that you responded to) agreed
>>> with him.
>>>
>>> Do you object to George's proposal that a CUA MUST ask 
>>> GET-CAPABILITY?
>>> Or are you saying you can go with a MUST or a MAY and that
>>> is is not that important to you?
>> I agree with both of you that a CUA MUST send the GET-CAPABILITY.
>> I agree with both of you that a CS MUST send the GET-CAPABILITY.
>> Everybody agrees a CS MUST implement and respond to the 
>> GET-CAPABILITY.
>> I was merely suggesting (but I would not fight over this if somebody
>> opposed it) that we could keep GET-CAPABILITY implementation and
>> response optional, as in the existent text. So a CS would still send
>> it and get back a REQUEST-STATUS:9.0;Unimplemented. In this case the
>> CS should simply assume the CUA uses the defaults for all properties -
>> we just have to make sure the defaults are reasonable, of course.
>> This would slightly simplify really naive implementations of CUAs
>> (say, a simple CGI which offers a read only view of a public agenda),
>> by allowing them to implement no command at all.
>> Bye,
>> 	andrea
>>>> I agree.
>>>>
>>>> I would add:
>>>>
>>>> 	The GET-CAPABILITY command MAY be implemented by a CUA.
>>>> 	If it's not, a CS MUST assume all capabilities take the default
>>>> 	values.
>>>
>
> <smime.p7s>



From owner-ietf-calendar@mail.imc.org  Thu Sep 19 15:33:38 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20040
	for <calsch-archive@lists.ietf.org>; Thu, 19 Sep 2002 15:33:37 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8JJNcT22784
	for ietf-calendar-bks; Thu, 19 Sep 2002 12:23:38 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JJNbk22780
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 12:23:37 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8JJNcR2003987
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 12:23:39 -0700
Message-ID: <3D8A21FD.4040700@Royer.com>
Date: Thu, 19 Sep 2002 13:14:05 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: iMIP
References: <C393827E-CBFF-11D6-8F78-003065A8EEFC@inet.it>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040901020808010001010402"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms040901020808010001010402
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


>> iMIP requires the 'From:' and other 822 headers. I don't think
>> we want to add that to CAP. Do we care?
> 
> 
> No, of course not. Headers are not part of the payload. Only the payload 
> of CAP and iMIP messages would need to be compatible.

At this point - it would not be iMIP compliant. So no, I do not
think that we should make CAP an iMIP binding. I think that iTIP
is the correct breaking point for the bindings.

In addition, iMIP mandates that ATTENDEE values me e-mail addresses (2.3).
In CAP they can be 'cap' URIs.

In addition iMIP says:

    Compliant applications MUST support signing
    and encrypting text/calendar attachments using a mechanism based on
    Security Multiparts for MIME [RFC-1847] to facilitate the
    authentication the originator of the iCalendar object.

Do we want to mandate that ALL CS's implement S/MIME to facilitate
the authentication of the originator? No, we have SASL and TLS for
that in CAP.


--------------ms040901020808010001010402
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkxOTE5MTQwNVowIwYJKoZIhvcNAQkEMRYEFIe+VSs1
74VxwgoGDO9vnctjSzi9MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB703a1YV+Ka4k24yBn
hlFaCDLu/WBjc6udVtAZN7HKk/3KFx9BqiUwYGPdsItjCo4K5S/KcpDD/JWIj1KHMlpLeHC5
LpkPTjpzGIaOOBE/Y11JmuKFp7xiwBpGhafm+OktG65qz/BAHZDquKO0OcKYt7wZxcNRqwGY
ecdUMUX0z0HFUWIWjJjGYmLhCd/EMXtxA+Oiwrc0HegNIDs4nvRyDBNQslgTapTtfiq0Ku/Y
R0nbOYHs9V8O9ko3Q62Ht6PGrpyQoO8a9wkjW/AGLdgmPppYzOBuzv2Z0fMgjQwPDYZSL1fD
UYdX6RuWR2hfrNn4Ekzg2weEtzXnx7/ZJg7lAAAAAAAA
--------------ms040901020808010001010402--



From owner-ietf-calendar@mail.imc.org  Thu Sep 19 16:10:40 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21589
	for <calsch-archive@lists.ietf.org>; Thu, 19 Sep 2002 16:10:40 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8JK5u623785
	for ietf-calendar-bks; Thu, 19 Sep 2002 13:05:56 -0700 (PDT)
Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JK5sk23781
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 13:05:55 -0700 (PDT)
Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50])
	by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g8JK5s5f015523
	for <ietf-calendar@imc.org>; Thu, 19 Sep 2002 22:05:55 +0200
Date: Thu, 19 Sep 2002 22:05:50 +0200
Subject: Re: iMIP
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
From: Andrea Campi <a.campi@inet.it>
To: ietf-calendar@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3D8A21FD.4040700@Royer.com>
Message-Id: <31790430-CC0B-11D6-B4FA-003065A8EEFC@inet.it>
X-Mailer: Apple Mail (2.546)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



On Thursday, September 19, 2002, at 09:14 PM, Doug Royer wrote:

>
>>> iMIP requires the 'From:' and other 822 headers. I don't think
>>> we want to add that to CAP. Do we care?
>> No, of course not. Headers are not part of the payload. Only the 
>> payload of CAP and iMIP messages would need to be compatible.
>
> At this point - it would not be iMIP compliant. So no, I do not
> think that we should make CAP an iMIP binding. I think that iTIP
> is the correct breaking point for the bindings.

OK, I appreciate your points, I had not considered some of those. So I 
drop my proposal.

So this means we needn't forbid more than one METHOD per text/calendar 
;-)

Bye,
	Andrea



From owner-ietf-calendar@mail.imc.org  Fri Sep 20 10:02:11 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22709
	for <calsch-archive@lists.ietf.org>; Fri, 20 Sep 2002 10:02:10 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8KDsvT12120
	for ietf-calendar-bks; Fri, 20 Sep 2002 06:54:57 -0700 (PDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KDsuk12116
	for <ietf-calendar@imc.org>; Fri, 20 Sep 2002 06:54:56 -0700 (PDT)
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8KDsqe10460
	for <ietf-calendar@imc.org>; Fri, 20 Sep 2002 06:54:52 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8KDspC10437
	for <ietf-calendar@imc.org>; Fri, 20 Sep 2002 06:54:51 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8KDsov09713
	for <ietf-calendar@imc.org>; Fri, 20 Sep 2002 07:54:50 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8KDsnf09646
	for <ietf-calendar@imc.org>; Fri, 20 Sep 2002 07:54:49 -0600 (MDT)
Message-ID: <3D8B28A8.5E9D0D58@oracle.com>
Date: Fri, 20 Sep 2002 09:54:48 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
References: <7558294D-CC00-11D6-8F78-003065A8EEFC@inet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



What I proposed was that both the CS and CUA MUST support
GET-CAPABILITY because it may make the draft simpler to
write. It may also make the protocol simpler by having,
at the start, each side clearly state what they support.
(But who should issue the command first, or does it matter?)

However, I do not have strong feelings about this, thus
I am fine with specifying that the CUA MAY or SHOULD support
GET-CAPABILITY.

George

Andrea Campi wrote:
> 
> On Thursday, September 19, 2002, at 05:56 PM, Doug Royer wrote:
> 
> >
> > I believe that you are stating that CAP should not change.
> > What you are suggesting now is what the draft currently states.
> >
> > Does anyone else agree with George that both the CS and CUA
> > MUST support GET-CAPABILITY? (I could go with MAY or MUST).
> 
> Sorry there's a misunderstanding somewhere.
> I read George proposal (and I strongly agree on that) as changing CAP
> to say both the CS and CUA MUST send GET-CAPABILITY as the first
> command in a session.
> I thought this was what you are agreeing to?
> 
> I simply added: we may want to leave: the CS MUST support
> GET-CAPABILITY, the CUA MAY.
> 
> Is this clearer?
> 
> >
> > -Doug
> >
> >
> > Andrea Campi wrote:
> >> On Wed, Sep 18, 2002 at 02:56:51PM -0600, Doug Royer wrote:
> >>> Andrea,
> >>>
> >>> If you read George's post, you will see that he thought it should
> >>> be a MUST (not a MAY), so my proposal (that you responded to) agreed
> >>> with him.
> >>>
> >>> Do you object to George's proposal that a CUA MUST ask
> >>> GET-CAPABILITY?
> >>> Or are you saying you can go with a MUST or a MAY and that
> >>> is is not that important to you?
> >> I agree with both of you that a CUA MUST send the GET-CAPABILITY.
> >> I agree with both of you that a CS MUST send the GET-CAPABILITY.
> >> Everybody agrees a CS MUST implement and respond to the
> >> GET-CAPABILITY.
> >> I was merely suggesting (but I would not fight over this if somebody
> >> opposed it) that we could keep GET-CAPABILITY implementation and
> >> response optional, as in the existent text. So a CS would still send
> >> it and get back a REQUEST-STATUS:9.0;Unimplemented. In this case the
> >> CS should simply assume the CUA uses the defaults for all properties -
> >> we just have to make sure the defaults are reasonable, of course.
> >> This would slightly simplify really naive implementations of CUAs
> >> (say, a simple CGI which offers a read only view of a public agenda),
> >> by allowing them to implement no command at all.
> >> Bye,
> >>      andrea
> >>>> I agree.
> >>>>
> >>>> I would add:
> >>>>
> >>>>    The GET-CAPABILITY command MAY be implemented by a CUA.
> >>>>    If it's not, a CS MUST assume all capabilities take the default
> >>>>    values.
> >>>
> >
> > <smime.p7s>


From owner-ietf-calendar@mail.imc.org  Fri Sep 20 17:22:00 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09019
	for <calsch-archive@lists.ietf.org>; Fri, 20 Sep 2002 17:22:00 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g8KLDei08352
	for ietf-calendar-bks; Fri, 20 Sep 2002 14:13:40 -0700 (PDT)
Received: from eeyore.jsoft.com (24-240-234-245.charter.com [24.240.234.245])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KLDZk08347
	for <ietf-calendar@imc.org>; Fri, 20 Sep 2002 14:13:36 -0700 (PDT)
Received: from jsoft.com (IDENT:ji8gJ7vZl/sTnsSdMEK5Z5nA2fJZVf5+@eeyore.jsoft.com [192.168.0.46])
	by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g8KL6o405101
	for <ietf-calendar@imc.org>; Fri, 20 Sep 2002 16:06:50 -0500
Message-ID: <3D8B8DE9.9050106@jsoft.com>
Date: Fri, 20 Sep 2002 16:06:49 -0500
From: Gary Frederick <gary.frederick@jsoft.com>
Organization: Jefferson Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Revised proposal
References: <7558294D-CC00-11D6-8F78-003065A8EEFC@inet.it> <3D8B28A8.5E9D0D58@oracle.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Sounds like everyone commenting is ok with MUST. MUST should make the standard a bit simpler. I have not seen a real benefit posted for MAY for the CUA.

Can we have an example conversation that shows a CUA connecting with a CS?
Would the conversation between a CS and a CS be the same?

I would like to see what the GET-CAPABILITY returns.

Gary



From owner-ietf-calendar@mail.imc.org  Wed Sep 25 12:23:10 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01321
	for <calsch-archive@lists.ietf.org>; Wed, 25 Sep 2002 12:23:09 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PFv8D08019
	for ietf-calendar-bks; Wed, 25 Sep 2002 08:57:08 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PFv7v08014
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 08:57:07 -0700 (PDT)
In-Reply-To: <3D81FB8C.8CC5A42@oracle.com>
To: George Babics <george.babics@oracle.com>
Cc: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09232002NP September 23, 2002
Message-ID: <OF13C46DD4.9DED39EC-ON85256C3F.0052AD8E-85256C3F.0057C685@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Wed, 25 Sep 2002 11:54:43 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09192002NP|September 19, 2002) at
 09/25/2002 11:50:53 AM,
	Serialize complete at 09/25/2002 11:50:53 AM
Content-Type: multipart/alternative; boundary="=_alternative 0057C67285256C3F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0057C67285256C3F_=
Content-Type: text/plain; charset="US-ASCII"

Georged replied on 09/13/2002 10:51:56 AM:
>   Shouldn't the CUA be able to detect that an event has a large
> inline attachment, and decide not to get the attachment but get
> the rest of the event? Or if the attachment is too big for
> the CUA, the attachment is not returned?

[Product deathmarches have a way of causing WG neglect so I appologize in 
advance if this is already been covered...]

We have no way to detect that kind of info in CAP last time I dived deep. 
Nor do we have any way to indicate this to the CS (or of the CS to 
indicate on the returend data "I would have sent you the 2 ATTACHments but 
they were both bigger than the size you said was your max allowed size.")

>                                            The CUA can display a
> message to the CU that the attachment was too big to download.

Perhaps you are thinking of IMAP where the MUA can retrieve the body 
structure of the message and then load down the parts it wants/needs... We 
dont have that in CAP though (although I think Pete put it in ICAP a few 
years ago...).

> Should the CU not be able to see the event because the attachment
> is too big?

No.  If the CUA cant handle ATTACHments then it should not ask for them. 

It would be poor CUA design to NOT download, say, a meeting for today just 
because my Palm does not have the space for the mongo attachment.  That 
would make me think that I was free at that time slot when in fact Im not 
and I would miss my meeting.

>   An inline attachment can easily get very big, especially, if the
> CUA does not support multipart. 

That is why the _intended_ use of the inline ATTACHment is for SMALL 
ATTACHments.  It would be considered an abuse to inline the 5.8M 
PowerPoint presentation although its unspecifed exactly how "small" small 
is.  Common sense should be applied here.

>                                 However, how often can a DESCRIPTION,
> SUMMARY, number of ATTENDEES, etc., be bigger than the maximum? What
> would a typical maximum be? 1K, 10K, 100K?

With regard to properties that you need to make the entry meaningfull (ie: 
SUMMARY, DESCRIPTION) where there can be ALTREPs the story is a bit 
different.  We have never put a limit on their size but we (collectively) 
expected that SUMMARY is the short text that describes the event (ie: the 
Subject line in the iMIP message or that is rendered in the 'view' of the 
calendar that a CU sees such as in Organizer, Outlook, etc.)  The 
DESCRIPTION property is "a more complete description" than what you find 
in SUMMARY.  This is typically the bigger, more complex information (much 
like the body of an email vs the Subject line). 

There is no limit to their sizes or to the size of the ALTREPs.  Nor is 
there a limit to the complexity of the ALTREPs; they can be single MIME 
elements (ie: text/html) or multipart elements themselves (ie: 
multipart/alternative with text/html, application/ms-tnef and 
application/postscript subelements) but thats a sidenote really....

The properties like SUBJECT or DESCRIPTION are necessary to properly 
present the entry to the CU in some fashion.  If they are missing then the 
entry is probably not very meaningful ("Hmm, George invited me to an event 
but he didnt send any Summary or detailed info about it...").  If the 
ATTACHment was missing then at least I know something about the entry 
("Hmm, George invited me to discuss the CAP design for multiparts and 
ATTACHments...") so I can make a more informed choice as to what to do.

All this begs the question: Why does it matter what a typical size for 
something is?  Hopefully you aren't designing anything (CAP or CAP engine) 
so that there are hard limits...

> > True - I mean - the CUA does it - out of scope for CAP.
> > The CUA can store the ALTREP or not, but not with CAP.

[This looks like Dougs response here but I missed it the 1st time 
around...]

Whoa!!!!  Why not _with_ CAP??  Ive yet to hear any good reason that a CUA 
cannot craft an entry that looks (in part) like:

multipart/related
    text/calendar (with CID:1.1)
        ...
        DESCRIPTION;ALTREP=CID:1.2:Agenda\n1) CAP design review\n...
        ...
    text/html (with CID:1.2)
        <HTML><HEAD><TITLE>CAP Design Review</TITLE></HEAD><BODY>
        <P><H1>Agenda:</H1><OL><LI>CAP Design</LI>...

Why cant a CUA send this to a CS using CAP?? 

The only reason I can think of is that the choice for a CS's back end 
storage is some dB engine/model that cant deal with multipart.  Sorry, 
thats not an acceptable justification to me or my users.  We no longer 
live in 'plain' ASCII email world and users are getting more and more used 
to richer data so I really really need to hear a very good reason that CAP 
should NOT support multipart.

>   Given ATTACHments and ALTREP are there still people out there who
> think support for multipart should be a MAY? If yes, let us know.
> (If there are people who say yes, I am fine with keeping it a
> MAY!)

I think that MAY is too weak myself given that iCalendar is already 
'multipart ready' (TM by me) with ATTACHments and ALTREPs.  I prefer 
SHOULD since its stronger and Ive yet to hear any reasons why we should 
NOT have multipart support out of the gates.  From 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

and

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

Given these Id say that supporting multipart definitely falls under 
"SHOULD" since multipart is NOT something that just 'enhances the product' 
unless you are coding to 1985 standards.  The concept of multipart has 
been in iCalendar since Day 1 (or maybe 2) and removing it in a followon 
protocol 4 years later is something that should be carefully weighted and 
not just (seemingly) arbitrarily done.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...


--=_alternative 0057C67285256C3F_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Georged replied on 09/13/2002 10:51:56 AM:<br>
&gt; &nbsp; Shouldn't the CUA be able to detect that an event has a large<br>
&gt; inline attachment, and decide not to get the attachment but get<br>
&gt; the rest of the event? Or if the attachment is too big for<br>
&gt; the CUA, the attachment is not returned?</tt></font>
<br>
<br><font size=2 face="sans-serif">[Product deathmarches have a way of
causing WG neglect so I appologize in advance if this is already been covered...]</font>
<br>
<br><font size=2 face="sans-serif">We have no way to detect that kind of
info in CAP last time I dived deep. &nbsp;Nor do we have any way to indicate
this to the CS (or of the CS to indicate on the returend data &quot;I would
have sent you the 2 ATTACHments but they were both bigger than the size
you said was your max allowed size.&quot;)</font>
<br>
<br><font size=2><tt>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;The CUA can display a<br>
&gt; message to the CU that the attachment was too big to download.<br>
</tt></font>
<br><font size=2 face="sans-serif">Perhaps you are thinking of IMAP where
the MUA can retrieve the body structure of the message and then load down
the parts it wants/needs... &nbsp;We dont have that in CAP though (although
I think Pete put it in ICAP a few years ago...).</font>
<br>
<br><font size=2><tt>&gt; Should the CU not be able to see the event because
the attachment<br>
&gt; is too big?<br>
</tt></font>
<br><font size=2 face="sans-serif">No. &nbsp;If the CUA cant handle ATTACHments
then it should not ask for them. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">It would be poor CUA design to NOT download,
say, a meeting for today just because my Palm does not have the space for
the mongo attachment. &nbsp;That would make me think that I was free at
that time slot when in fact Im not and I would miss my meeting.</font>
<br>
<br><font size=2><tt>&gt; &nbsp; An inline attachment can easily get very
big, especially, if the<br>
&gt; CUA does not support multipart. <br>
</tt></font>
<br><font size=2 face="sans-serif">That is why the <u>_intended_</u> use
of the inline ATTACHment is for SMALL ATTACHments. &nbsp;It would be considered
an abuse to inline the 5.8M PowerPoint presentation although its unspecifed
exactly how &quot;small&quot; small is. &nbsp;Common sense should be applied
here.</font>
<br>
<br><font size=2><tt>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; However,
how often can a DESCRIPTION,<br>
&gt; SUMMARY, number of ATTENDEES, etc., be bigger than the maximum? What<br>
&gt; would a typical maximum be? 1K, 10K, 100K?</tt></font>
<br>
<br><font size=2 face="sans-serif">With regard to properties that you need
to make the entry meaningfull (ie: SUMMARY, DESCRIPTION) where there can
be ALTREPs the story is a bit different. &nbsp;We have never put a limit
on their size but we (collectively) expected that SUMMARY is the short
text that describes the event (ie: the Subject line in the iMIP message
or that is rendered in the 'view' of the calendar that a CU sees such as
in Organizer, Outlook, etc.) &nbsp;The DESCRIPTION property is &quot;a
more complete description&quot; than what you find in SUMMARY. &nbsp;This
is typically the bigger, more complex information (much like the body of
an email vs the Subject line). &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">There is no limit to their sizes or
to the size of the ALTREPs. &nbsp;Nor is there a limit to the complexity
of the ALTREPs; they can be single MIME elements (ie: text/html) or multipart
elements themselves (ie: multipart/alternative with text/html, application/ms-tnef
and application/postscript subelements) but thats a sidenote really....</font>
<br>
<br><font size=2 face="sans-serif">The properties like SUBJECT or DESCRIPTION
are necessary to properly present the entry to the CU in some fashion.
&nbsp;If they are missing then the entry is probably not very meaningful
(&quot;Hmm, George invited me to an event but he didnt send any Summary
or detailed info about it...&quot;). &nbsp;If the ATTACHment was missing
then at least I know something about the entry (&quot;Hmm, George invited
me to discuss the CAP design for multiparts and ATTACHments...&quot;) so
I can make a more informed choice as to what to do.</font>
<br>
<br><font size=2 face="sans-serif">All this begs the question: Why does
it matter what a typical size for something is? &nbsp;Hopefully you aren't
designing anything (CAP or CAP engine) so that there are hard limits...</font>
<br>
<br><font size=2><tt>&gt; &gt; True - I mean - the CUA does it - out of
scope for CAP.<br>
&gt; &gt; The CUA can store the ALTREP or not, but not with CAP.<br>
</tt></font>
<br><font size=2 face="sans-serif">[This looks like Dougs response here
but I missed it the 1st time around...]</font>
<br>
<br><font size=2 face="sans-serif">Whoa!!!! &nbsp;Why not <u>_with_</u>
CAP?? &nbsp;Ive yet to hear any good reason that a CUA cannot craft an
entry that looks (in part) like:</font>
<br>
<br><font size=2><tt>multipart/related</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; text/calendar (with CID:1.1)</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; ...</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; DESCRIPTION;ALTREP=CID:1.2:Agenda\n1)
CAP design review\n...</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; ...</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; text/html (with CID:1.2)</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &lt;HTML&gt;&lt;HEAD&gt;&lt;TITLE&gt;CAP
Design Review&lt;/TITLE&gt;&lt;/HEAD&gt;&lt;BODY&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &lt;P&gt;&lt;H1&gt;Agenda:&lt;/H1&gt;&lt;OL&gt;&lt;LI&gt;CAP
Design&lt;/LI&gt;...</tt></font>
<br>
<br><font size=2 face="sans-serif">Why cant a CUA send this to a CS using
CAP?? &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">The only reason I can think of is that
the choice for a CS's back end storage is some dB engine/model that cant
deal with multipart. &nbsp;Sorry, thats not an acceptable justification
to me or my users. &nbsp;We no longer live in 'plain' ASCII email world
and users are getting more and more used to richer data so I really really
need to hear a very good reason that CAP should NOT support multipart.</font>
<br>
<br><font size=2><tt>&gt; &nbsp; Given ATTACHments and ALTREP are there
still people out there who<br>
&gt; think support for multipart should be a MAY? If yes, let us know.<br>
&gt; (If there are people who say yes, I am fine with keeping it a<br>
&gt; MAY!)<br>
</tt></font>
<br><font size=2 face="sans-serif">I think that MAY is too weak myself
given that iCalendar is already 'multipart ready' (TM by me) with ATTACHments
and ALTREPs. &nbsp;I prefer SHOULD since its stronger and Ive yet to hear
any reasons why we should NOT have multipart support out of the gates.
&nbsp;From 2119:</font>
<br>
<br><font size=2><tt>3. SHOULD &nbsp; This word, or the adjective &quot;RECOMMENDED&quot;,
mean that there<br>
 &nbsp; may exist valid reasons in particular circumstances to ignore a<br>
 &nbsp; particular item, but the full implications must be understood and<br>
 &nbsp; carefully weighed before choosing a different course.</tt></font>
<br>
<br><font size=2 face="sans-serif">and</font>
<br>
<br><font size=2><tt>5. MAY &nbsp; This word, or the adjective &quot;OPTIONAL&quot;,
mean that an item is<br>
 &nbsp; truly optional. &nbsp;One vendor may choose to include the item
because a<br>
 &nbsp; particular marketplace requires it or because the vendor feels
that<br>
 &nbsp; it enhances the product while another vendor may omit the same
item.<br>
 &nbsp; An implementation which does not include a particular option MUST
be<br>
 &nbsp; prepared to interoperate with another implementation which does<br>
 &nbsp; include the option, though perhaps with reduced functionality.
In the<br>
 &nbsp; same vein an implementation which does include a particular option<br>
 &nbsp; MUST be prepared to interoperate with another implementation which<br>
 &nbsp; does not include the option (except, of course, for the feature
the<br>
 &nbsp; option provides.)</tt></font>
<br>
<br><font size=2 face="sans-serif">Given these Id say that supporting multipart
definitely falls under &quot;SHOULD&quot; since multipart is NOT something
that just 'enhances the product' unless you are coding to 1985 standards.
&nbsp;The concept of multipart has been in iCalendar since Day 1 (or maybe
2) and removing it in a followon protocol 4 years later is something that
should be carefully weighted and not just (seemingly) arbitrarily done.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
<br>
--=_alternative 0057C67285256C3F_=--


From owner-ietf-calendar@mail.imc.org  Wed Sep 25 13:52:30 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04468
	for <calsch-archive@lists.ietf.org>; Wed, 25 Sep 2002 13:52:29 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PHXpX14238
	for ietf-calendar-bks; Wed, 25 Sep 2002 10:33:51 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PHXnv14233
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 10:33:49 -0700 (PDT)
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09232002NP September 23, 2002
Message-ID: <OF1F89B418.514E7881-ON85256C3F.005D0B0E-85256C3F.005F44D7@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Wed, 25 Sep 2002 13:18:35 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09192002NP|September 19, 2002) at
 09/25/2002 01:27:35 PM,
	Serialize complete at 09/25/2002 01:27:35 PM
Content-Type: multipart/alternative; boundary="=_alternative 005F44D285256C3F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 005F44D285256C3F_=
Content-Type: text/plain; charset="US-ASCII"

Doug wrote on 09/12/2002 03:50:38 PM CST:
> If the endpoint does not want large iCalendar objects, it is
> free to set its size CAPABILITY to an acceptable limit. However
> if it is set to unlimited size, then the endpoint is saying that
> it *is* acceptable.

I think there is a difference between what is the maximum size object (ie: 
VEVENT) that a CUA/CS wants and the maximum size non-inlined ATTACHment or 
ALTREP data.  I for one would definitely NOT like to 'miss' a meeting 
because the large ATTACHment was over some limit when the actual VEVENT 
size is not.  This is poor design if that can happen!  Then again, if the 
CUA is pressed for space, it should consider NOT asking for ATTACHments...

In Draft 09b the relevant text is:

      MAX-COMPONENT-SIZE
                        1     A positive integer value that specifies
                              the size of the largest iCalendar
                              object that the server will accept in
                              octets. Objects larger than this will be
                              rejected. The absence of this attribute
                              indicates no limit. This is also the
                              maximum value of any BEEP payload
                              the CS will accept or send.

This is talking about an "iCalendar object" which does NOT necessarily 
include the related MIME body parts in a multipart stream.  This could 
relate to ATTACHments if they are inlined but this does NOT cover the size 
of ALTREPs (at least not as currently written).  Perhaps a 
MAX-ATTACHMENT-SIZE is necessary as well... (Would it be per ATTACHment or 
total?  I can see either side as being valid...) 

A new MAX-ATTACHMENT-SIZE would not cover any ALTREPs though so should 
they be folded into the MAX-COMPONENT-SIZE text or should we have another 
way to limit their size.  Since ALTREP can be added to several properties 
(including TBD ones from SKiCAL, etc) Im inclined to NOT factor them into 
the MAX-COMPONENT-SIZE.  Rather a something like a MAX-EXTERNAL-SIZE could 
be created to cover the largest size for all 'external' (to the iCalendar 
object yet still in the MIME stream)...

Also, if we adopt a MAX-ATTACHMENT-SIZE then we need to be explicit in how 
an inlined ATTACHment is factored into the octet counts: does it go under 
MAX-COMPONENT-SIZE or under MAX-ATTACHMENT-SIZE.  I for one would say that 
if its inlined then its under MAX-COMPONENT-SIZE and NOT under 
MAX-ATTACHMENT-SIZE...

> I think you got off of the path here, which was: *Only* when the
> other endpoint can not do multipart. If the other endpoint can
> do multipart, then multipart IS acceptable and no conversion
> to inline is needed.

Ok, just to be crytal clear on this (in case we actually draft up some 
text to cover it at some point): SHOULD/MUST the CS inline ATTACHments 
ONLY if the requestor is NOT multipart savy and has requested non-inlined 
ATTACHments?  Can the CS do the non-inline -> inline conversion at its 
whim or only for the non-multipart case.  That is, if I send multipart 
data to a multipart savy CS, will the CS have the option to inline the 
ATTACHments I send when I turn around and retrieve them back?  Or MUST it 
preserve the structure whenver possible?

I think we are in very close agreement on this and I have a bunch of other 
WG backlog to get thru but Im trying to avoid any vagueness on this in CAP 
so we dont have a repeat of the multipart pains from iCalendar.

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 005F44D285256C3F_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug wrote on </tt></font><font size=2 face="sans-serif">09/12/2002
03:50:38 PM CST</font><font size=2><tt>:<br>
&gt; If the endpoint does not want large iCalendar objects, it is<br>
&gt; free to set its size CAPABILITY to an acceptable limit. However<br>
&gt; if it is set to unlimited size, then the endpoint is saying that<br>
&gt; it *is* acceptable.<br>
</tt></font>
<br><font size=2 face="sans-serif">I think there is a difference between
what is the maximum size object (ie: VEVENT) that a CUA/CS wants and the
maximum size non-inlined ATTACHment or ALTREP data. &nbsp;I for one would
definitely NOT like to 'miss' a meeting because the large ATTACHment was
over some limit when the actual VEVENT size is not. &nbsp;This is poor
design if that can happen! &nbsp;Then again, if the CUA is pressed for
space, it should consider NOT asking for ATTACHments...</font>
<br>
<br><font size=2 face="sans-serif">In Draft 09b the relevant text is:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; MAX-COMPONENT-SIZE<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; A positive integer value that specifies<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the size of the largest iCalendar<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;object that the server will accept in<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;octets. Objects larger than this will
be<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;rejected. The absence of this attribute<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;indicates no limit. This is also the<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;maximum value of any BEEP payload<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the CS will accept or send.</tt></font>
<br>
<br><font size=2 face="sans-serif">This is talking about an &quot;iCalendar
object&quot; which does NOT necessarily include the related MIME body parts
in a multipart stream. &nbsp;This could relate to ATTACHments if they are
inlined but this does NOT cover the size of ALTREPs (at least not as currently
written). &nbsp;Perhaps a MAX-ATTACHMENT-SIZE is necessary as well... (Would
it be per ATTACHment or total? &nbsp;I can see either side as being valid...)
</font>
<br>
<br><font size=2 face="sans-serif">A new MAX-ATTACHMENT-SIZE would not
cover any ALTREPs though so should they be folded into the MAX-COMPONENT-SIZE
text or should we have another way to limit their size. &nbsp;Since ALTREP
can be added to several properties (including TBD ones from SKiCAL, etc)
Im inclined to NOT factor them into the MAX-COMPONENT-SIZE. &nbsp;Rather
a something like a MAX-EXTERNAL-SIZE could be created to cover the largest
size for all 'external' (to the iCalendar object yet still in the MIME
stream)...</font>
<br>
<br><font size=2 face="sans-serif">Also, if we adopt a MAX-ATTACHMENT-SIZE
then we need to be explicit in how an inlined ATTACHment is factored into
the octet counts: does it go under MAX-COMPONENT-SIZE or under MAX-ATTACHMENT-SIZE.
&nbsp;I for one would say that if its inlined then its under MAX-COMPONENT-SIZE
and NOT under MAX-ATTACHMENT-SIZE...</font>
<br>
<br><font size=2><tt>&gt; I think you got off of the path here, which was:
*Only* when the<br>
&gt; other endpoint can not do multipart. If the other endpoint can<br>
&gt; do multipart, then multipart IS acceptable and no conversion<br>
&gt; to inline is needed.</tt></font>
<br>
<br><font size=2 face="sans-serif">Ok, just to be crytal clear on this
(in case we actually draft up some text to cover it at some point): SHOULD/MUST
the CS inline ATTACHments ONLY if the requestor is NOT multipart savy and
has requested non-inlined ATTACHments? &nbsp;Can the CS do the non-inline
-&gt; inline conversion at its whim or only for the non-multipart case.
&nbsp;That is, if I send multipart data to a multipart savy CS, will the
CS have the option to inline the ATTACHments I send when I turn around
and retrieve them back? &nbsp;Or MUST it preserve the structure whenver
possible?</font>
<br>
<br><font size=2 face="sans-serif">I think we are in very close agreement
on this and I have a bunch of other WG backlog to get thru but Im trying
to avoid any vagueness on this in CAP so we dont have a repeat of the multipart
pains from iCalendar.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 005F44D285256C3F_=--


From owner-ietf-calendar@mail.imc.org  Wed Sep 25 14:09:00 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05191
	for <calsch-archive@lists.ietf.org>; Wed, 25 Sep 2002 14:08:59 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PI1Fi14917
	for ietf-calendar-bks; Wed, 25 Sep 2002 11:01:15 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PI1Fv14910
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 11:01:15 -0700 (PDT)
In-Reply-To: <3D8236B9.46D8F278@Royer.com>
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09232002NP September 23, 2002
Message-ID: <OF84F28810.41084FB7-ON85256C3F.0062154D-85256C3F.0062ADA7@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Wed, 25 Sep 2002 13:55:49 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09192002NP|September 19, 2002) at
 09/25/2002 01:55:01 PM,
	Serialize complete at 09/25/2002 01:55:01 PM
Content-Type: multipart/alternative; boundary="=_alternative 0062ADA285256C3F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0062ADA285256C3F_=
Content-Type: text/plain; charset="US-ASCII"

Doug wrote on 09/13/2002 03:04:25 PM:
> Multipart still does not solve the size problem. I do not
> think there is a solution If you ask for all of a component,
> the size of the result is the sum of all of its body parts. It
> is not going to get smaller because the ATTACH or ALTREP value
> is in another body part.

I was with you up to this point.  The Draft 9b says:

      MAX-COMPONENT-SIZE
                        1     A positive integer value that specifies
                              the size of the largest iCalendar
                              object that the server will accept in
                              octets. [Snip]

An iCalendar object is defined as:

   Object -  A generic name for any component, property, parameter, or
      value type to be used in iCalendar.

As such, the ALTREP and ATTACHment data external to the 
BEGIN:VCALENDAR...END:VCALENDAR boundaries are not part of that 'object'. 
They are related to it but not part of it.

> We have no way to say:
> 
>    SELECT * (except other body parts) FROM VEVENT
> 
> 
> And I don't think we need to. Limited memory devices or those
> limited to tiny bandwidths will need to just ask for want they
> want.

I can see a use for having a "NOT" in the selection process.  "Give me all 
properties except ATTACH and VALARM" is a quite logical desire.  Its MUCH 
shorter than expressly listing _every_ property except those... 

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0062ADA285256C3F_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug wrote on 09/13/2002 03:04:25 PM:<br>
&gt; Multipart still does not solve the size problem. I do not<br>
&gt; think there is a solution If you ask for all of a component,<br>
&gt; the size of the result is the sum of all of its body parts. It<br>
&gt; is not going to get smaller because the ATTACH or ALTREP value<br>
&gt; is in another body part.<br>
</tt></font>
<br><font size=2 face="sans-serif">I was with you up to this point. &nbsp;The
Draft 9b says:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; MAX-COMPONENT-SIZE<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; A positive integer value that specifies<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the size of the largest iCalendar<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;object that the server will accept in<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;octets. [Snip]</tt></font>
<br>
<br><font size=2 face="sans-serif">An iCalendar object is defined as:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;Object - &nbsp;A generic name for any
component, property, parameter, or<br>
 &nbsp; &nbsp; &nbsp;value type to be used in iCalendar.</tt></font><font size=3><tt><br>
</tt></font>
<br><font size=2 face="sans-serif">As such, the ALTREP and ATTACHment data
external to the BEGIN:VCALENDAR...END:VCALENDAR boundaries are not part
of that 'object'. &nbsp;They are related to it but not part of it.</font>
<br>
<br><font size=2><tt>&gt; We have no way to say:<br>
&gt; <br>
&gt; &nbsp; &nbsp;SELECT * (except other body parts) FROM VEVENT<br>
&gt; <br>
&gt; <br>
&gt; And I don't think we need to. Limited memory devices or those<br>
&gt; limited to tiny bandwidths will need to just ask for want they<br>
&gt; want.<br>
</tt></font>
<br><font size=2 face="sans-serif">I can see a use for having a &quot;NOT&quot;
in the selection process. &nbsp;&quot;Give me all properties except ATTACH
and VALARM&quot; is a quite logical desire. &nbsp;Its MUCH shorter than
expressly listing _every_ property except those... &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0062ADA285256C3F_=--


From owner-ietf-calendar@mail.imc.org  Wed Sep 25 14:09:03 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05205
	for <calsch-archive@lists.ietf.org>; Wed, 25 Sep 2002 14:09:02 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PI1F814913
	for ietf-calendar-bks; Wed, 25 Sep 2002 11:01:15 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PI1Ev14908
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 11:01:14 -0700 (PDT)
In-Reply-To: <3D810F19.96C570B4@Royer.com>
To: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V60_09232002NP September 23, 2002
Message-ID: <OF8CD811F5.BD5A0FD8-ON85256C3F.00602C89-85256C3F.0061B9CF@iris.com>
From: Bruce_Kahn@notesdev.ibm.com
Date: Wed, 25 Sep 2002 13:45:25 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09192002NP|September 19, 2002) at
 09/25/2002 01:55:00 PM,
	Serialize complete at 09/25/2002 01:55:00 PM
Content-Type: multipart/alternative; boundary="=_alternative 0061B9CB85256C3F_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a multipart message in MIME format.
--=_alternative 0061B9CB85256C3F_=
Content-Type: text/plain; charset="US-ASCII"

Doug replied on 09/12/2002 06:03:05 PM:
> > Except that the mail server does not automagically include a
> > referenced MIDs contents in another message.
> 
> Okay - why do I care? :-)

It was your example.  You replied to George:

If the value is a MID, I would expect one or two body parts - depending
if the CS has the contents of the MID or not. This is no different
than e-mail.

I was merely trying to point out that in email, the mail server (POP3, 
IMAP, etc) does NOT automagically include the referenced MID content when 
sending down something like MHTML.  You seem to expect it to in CAP and 
that _is_ different than e-mail.  In email, my MUA must go find the 
referenced MID content and then render it properly.  In your example, the 
CS did that for the CUA.  Thats new behaviour Ive not seen described 
yet...

If you expect the CS to automagically include the referended MID/CID 
ATTACHments then that needs to be put into the spec.  One thing you need 
to be careful of in doing this kind of magical substitution is that the CS 
does not reuse the MID/CID from a different MIME streams. 

That is, if CID: 1234@foo.org/Part1.3 is used in one VEVENT that already 
exists and you create a new VEVENT that uses 
ATTACH:MID:1234@foo.org/Part1.3 then there can be a problem including the 
content of CID:1234@foo.org/Part1.3 into the new MIME stream since the MID 
is now no longer globally unique, it exists in the original stream and the 
new one the CS just created.  Thats bad.

Perhaps we need a command that allows a CUA to directly access ATTACHments 
by MID/CID or at least for use when dealing with ATTACHments that are 
other MIME entities...

> > Im not sure you can copy the MIDs contents into another message's body
> > part (effectively making it a CID now) since there is only 1 MID per
> > stream and the included data is no longer referenced by a MID (its not
> > a message now, its a body part of another message).
> 
> You don't copy it, but you can reference it (you would get one
> body part containing a URI to a MID). 

Thats not what you just said:

I would have to allow for and expect that I could get
a MIME object with one or two body parts. One text/calendar,
the other the CID contents (if they exist - and they should).
If the value is a MID, I would expect one or two body parts - depending
if the CS has the contents of the MID or not.

The last bit clearly says that you would expect the CS to include the 
referenced MID so thats copying it! 

Otherwise, we need a mechansim in CAP to allow the CUA to retrieved the 
referenced MIDs from the CS...

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0061B9CB85256C3F_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Doug replied on 09/12/2002 06:03:05 PM:<br>
&gt; &gt; Except that the mail server does not automagically include a<br>
&gt; &gt; referenced MIDs contents in another message.<br>
&gt; <br>
&gt; Okay - why do I care? :-)<br>
</tt></font>
<br><font size=2 face="sans-serif">It was your example. &nbsp;You replied
to George:</font>
<br>
<br><font size=2><tt>If the value is a MID, I would expect one or two body
parts - depending<br>
if the CS has the contents of the MID or not. This is no different<br>
than e-mail.</tt></font>
<br>
<br><font size=2 face="sans-serif">I was merely trying to point out that
in email, the mail server (POP3, IMAP, etc) does NOT automagically include
the referenced MID content when sending down something like MHTML. &nbsp;You
seem to expect it to in CAP and that _is_ different than e-mail. &nbsp;In
email, my MUA must go find the referenced MID content and then render it
properly. &nbsp;In your example, the CS did that for the CUA. &nbsp;Thats
new behaviour Ive not seen described yet...</font>
<br>
<br><font size=2 face="sans-serif">If you expect the CS to automagically
include the referended MID/CID ATTACHments then that needs to be put into
the spec. &nbsp;One thing you need to be careful of in doing this kind
of magical substitution is that the CS does not reuse the MID/CID from
a different MIME streams. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">That is, if CID: 1234@foo.org/Part1.3
is used in one VEVENT that already exists and you create a new VEVENT that
uses ATTACH:MID:1234@foo.org/Part1.3 then there can be a problem including
the content of CID:1234@foo.org/Part1.3 into the new MIME stream since
the MID is now no longer globally unique, it exists in the original stream
and the new one the CS just created. &nbsp;Thats bad.</font>
<br>
<br><font size=2 face="sans-serif">Perhaps we need a command that allows
a CUA to directly access ATTACHments by MID/CID or at least for use when
dealing with ATTACHments that are other MIME entities...</font>
<br>
<br><font size=2><tt>&gt; &gt; Im not sure you can copy the MIDs contents
into another message's body<br>
&gt; &gt; part (effectively making it a CID now) since there is only 1
MID per<br>
&gt; &gt; stream and the included data is no longer referenced by a MID
(its not<br>
&gt; &gt; a message now, its a body part of another message).<br>
&gt; <br>
&gt; You don't copy it, but you can reference it (you would get one<br>
&gt; body part containing a URI to a MID). </tt></font>
<br>
<br><font size=2 face="sans-serif">Thats not what you just said:</font>
<br>
<br><font size=2><tt>I would have to allow for and expect that I could
get<br>
a MIME object with one or two body parts. One text/calendar,<br>
the other the CID contents (if they exist - and they should).<br>
If the value is a MID, I would expect one or two body parts - depending<br>
if the CS has the contents of the MID or not.</tt></font>
<br>
<br><font size=2 face="sans-serif">The last bit clearly says that you would
expect the CS to include the referenced MID so thats copying it! &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Otherwise, we need a mechansim in CAP
to allow the CUA to retrieved the referenced MIDs from the CS...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@notesdev.ibm.com<br>
Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>
IBM Software Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0061B9CB85256C3F_=--


From owner-ietf-calendar@mail.imc.org  Wed Sep 25 14:46:34 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06329
	for <calsch-archive@lists.ietf.org>; Wed, 25 Sep 2002 14:46:33 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PIcXV16340
	for ietf-calendar-bks; Wed, 25 Sep 2002 11:38:33 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PIcVv16336
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 11:38:31 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8PIcWR2017922
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 11:38:32 -0700
Message-ID: <3D91FFB6.4040303@Royer.com>
Date: Wed, 25 Sep 2002 12:25:58 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <OF13C46DD4.9DED39EC-ON85256C3F.0052AD8E-85256C3F.0057C685@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070600070005070000040609"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms070600070005070000040609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


>
> 
>  > > True - I mean - the CUA does it - out of scope for CAP.
>  > > The CUA can store the ALTREP or not, but not with CAP.
> 
> [This looks like Dougs response here but I missed it the 1st time 
> around...]
> 
> Whoa!!!!  Why not _with_ CAP??  Ive yet to hear any good reason that a 
> CUA cannot craft an entry that looks (in part) like:

The topic was when the other endpoint can not handle multipart
AND it can not transfer that large of an inline object.

Should the CUA throw it away? Or can (MAY) it store the
attachment its self?



--------------ms070600070005070000040609
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkyNTE4MjU1OVowIwYJKoZIhvcNAQkEMRYEFJcDwt6l
f2RlrdW0LJrHgjpqxa5gMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQA2A00qF5I+gtGee4Yu
UZJbZ0jVj7LOQ31JKkjytJtLXmtwTOSHlKgE+YGIdKRp1jcKBqs/aJI2AV6K0Wi2DSPb53UQ
QSaFEe55dtiJCScXR9DAWuDepO5REroW8ffKln3DthxOx+Thr+wrtiQicUNbjgofEr9iqEel
7ENxKb0Gku345TmSTHoSk8DIArW4QcJDvUuet8y7GTYgECwwhp5ubToAi1OyrDaREaU9rEmB
lxzZ13ZSccDBmgx7Y2IRex3qos7KSxbkAJY8/WwgjjHP62xkKegRKJXQ1yhiN8Bdbjx5jxIn
Jpb5nsh3P8sjD/yussfk43cWESZDKHPSvkdKAAAAAAAA
--------------ms070600070005070000040609--



From owner-ietf-calendar@mail.imc.org  Wed Sep 25 15:04:43 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06818
	for <calsch-archive@lists.ietf.org>; Wed, 25 Sep 2002 15:04:42 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PIqTt17692
	for ietf-calendar-bks; Wed, 25 Sep 2002 11:52:29 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PIqRv17688
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 11:52:27 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8PIqSR2018015
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 11:52:29 -0700
Message-ID: <3D9202F8.3000807@Royer.com>
Date: Wed, 25 Sep 2002 12:39:52 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <OF1F89B418.514E7881-ON85256C3F.005D0B0E-85256C3F.005F44D7@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090703000807060302050707"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms090703000807060302050707
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


>  > I think you got off of the path here, which was: *Only* when the
>  > other endpoint can not do multipart. If the other endpoint can
>  > do multipart, then multipart IS acceptable and no conversion
>  > to inline is needed.
> 
> Ok, just to be crytal clear on this (in case we actually draft up some 
> text to cover it at some point): SHOULD/MUST the CS inline ATTACHments 
> ONLY if the requestor is NOT multipart savy and has requested 
> non-inlined ATTACHments?  Can the CS do the non-inline -> inline 
> conversion at its whim or only for the non-multipart case.  That is, if 
> I send multipart data to a multipart savy CS, will the CS have the 
> option to inline the ATTACHments I send when I turn around and retrieve 
> them back?  Or MUST it preserve the structure whenver possible?

I would think it MUST preserve the structure whenever possible.
And in this context, that means if the CS gets it multipart, then
the CS MUST send it back multipart when the CUA supports multipart.

--------------ms090703000807060302050707
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkyNTE4Mzk1MlowIwYJKoZIhvcNAQkEMRYEFF3L6df6
GsPpH60xDBn+wtk9df2fMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB018qKfQS0poMENAxp
p4d2cGb/xqoNnLZFUrHZxTIL9wSGJRsuoIiOpFU75qDg6J9G9qlFRYYE/7OpO6T5UwsR1jI/
hvNXFHCbf2l+5uCt8gfL/7goa7F1bdHCjMUDqXFgENUCHUte1RVEZEKdBQ+bzd/98+dk7zzP
h3hRpSFzI5PP2gN6Slye2J5L4apF8shXNzLFsTDlp64AqAD/8J4tyHX6sF0EQpUHQkTpQJ39
/vhCMFhoJ05e2LLxlqIM3NJUcjtCR0dTIcmCPuqDeNb+Jc/yOId19zYg4kRDKgsms4Js+I2M
+aH78J7d9AUclz9tlvG44HB2C1q/z1lktVLRAAAAAAAA
--------------ms090703000807060302050707--



From owner-ietf-calendar@mail.imc.org  Wed Sep 25 15:06:11 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06852
	for <calsch-archive@lists.ietf.org>; Wed, 25 Sep 2002 15:06:10 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PIxCr17936
	for ietf-calendar-bks; Wed, 25 Sep 2002 11:59:12 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PIxAv17927
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 11:59:10 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8PIxBR2018051
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 11:59:12 -0700
Message-ID: <3D92048E.8010401@Royer.com>
Date: Wed, 25 Sep 2002 12:46:38 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: [Fwd: How To Handle Attachments]
References: <OF8CD811F5.BD5A0FD8-ON85256C3F.00602C89-85256C3F.0061B9CF@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000108020905020109000008"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms000108020905020109000008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug replied on 09/12/2002 06:03:05 PM:
>  > > Except that the mail server does not automagically include a
>  > > referenced MIDs contents in another message.
>  >
>  > Okay - why do I care? :-)
> 
> It was your example.  You replied to George:
> 
> If the value is a MID, I would expect one or two body parts - depending
> if the CS has the contents of the MID or not. This is no different
> than e-mail.
> 
> I was merely trying to point out that in email, the mail server (POP3, 
> IMAP, etc) does NOT automagically include the referenced MID content 
> when sending down something like MHTML.  You seem to expect it to in CAP 
> and that _is_ different than e-mail. 

No, I am saying that it is valid MIME, so the CUA must be ready for it.
(And what is MHTML?)

 > In email, my MUA must go find the
> referenced MID content and then render it properly.  In your example, 
> the CS did that for the CUA.  Thats new behaviour Ive not seen described 
> yet...

No, I meant that you can get a MID and the CS only has to return
the MID (not the content).

> If you expect the CS to automagically include the referended MID/CID 
> ATTACHments then that needs to be put into the spec.  One thing you need 
> to be careful of in doing this kind of magical substitution is that the 
> CS does not reuse the MID/CID from a different MIME streams.  

I agree - no. I was saying that some MUA's use MID's which CAN
point to themselves. (MID == myself:body-part-3) and (CID == body-part-3)
are the same. So we must specify that external - MIDs are not
fetched by the CS (or CUA?), but internal MIDs and all CIDs are stored
by multipart aware CSs.



--------------ms000108020905020109000008
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkyNTE4NDYzOFowIwYJKoZIhvcNAQkEMRYEFO6LyLL0
Xj2xlMVUY0S4CSVBEtYwMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCnKIzcPvW5h1fydFBv
jcyQp+UlhckFD11/oiGXDkF50QZaO2m8SV8czxelIfji5utFsLcsZCX4wS5AXrPlMroHpLwd
xQvyhGO+XfdcfCVat6CgMg81/wtZIxin/PzzMRbJMd7n7IH/kUKbbYwx1AD3e88Cff4hNOpF
vcHyMumMv0y1DTYn8YUKHg0OdNQlvgH2zxH/to7/KU/A35mkq0FQ7BsCEgOEqsm5Ax73TaL5
H+QFqfJs7oCw+cVgL68pIQJVSLLX5ilFAXWRa9ECREceK1VRGq/bVQ488PdeANtld48sG5kf
LmL5nxbELjabLJB5F9SqwqQhYyAw3agFJuUEAAAAAAAA
--------------ms000108020905020109000008--



From owner-ietf-calendar@mail.imc.org  Wed Sep 25 15:14:56 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07188
	for <calsch-archive@lists.ietf.org>; Wed, 25 Sep 2002 15:14:55 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PJ1Vw18264
	for ietf-calendar-bks; Wed, 25 Sep 2002 12:01:31 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PJ1Tv18258
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 12:01:30 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8PJ1VR2018086
	for <ietf-calendar@imc.org>; Wed, 25 Sep 2002 12:01:31 -0700
Message-ID: <3D920519.40208@Royer.com>
Date: Wed, 25 Sep 2002 12:48:57 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <OF84F28810.41084FB7-ON85256C3F.0062154D-85256C3F.0062ADA7@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000900000908040105010106"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms000900000908040105010106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


So what are you proposing as the solution? Are you
saying that because an endpoint supports multipart
that it MUST allow for unlimited sizes in the body parts?

Or are you saying that we should define MAX-COMPONENT-SIZE
to include body parts?

Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug wrote on 09/13/2002 03:04:25 PM:
>  > Multipart still does not solve the size problem. I do not
>  > think there is a solution If you ask for all of a component,
>  > the size of the result is the sum of all of its body parts. It
>  > is not going to get smaller because the ATTACH or ALTREP value
>  > is in another body part.
> 
> I was with you up to this point.  The Draft 9b says:
> 
>       MAX-COMPONENT-SIZE
>                        1     A positive integer value that specifies
>                              the size of the largest iCalendar
>                              object that the server will accept in
>                              octets. [Snip]
> 
> An iCalendar object is defined as:
> 
>    Object -  A generic name for any component, property, parameter, or
>      value type to be used in iCalendar.
> 
> As such, the ALTREP and ATTACHment data external to the 
> BEGIN:VCALENDAR...END:VCALENDAR boundaries are not part of that 
> 'object'.  They are related to it but not part of it.

--------------ms000900000908040105010106
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkyNTE4NDg1N1owIwYJKoZIhvcNAQkEMRYEFHF03jvT
XUjLJfb3a5BmNofY3TXPMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAVCVxzuAwr91Db2R2e
pfZ3fj7ucxVCu60yetjBEvWuvs7qgj7dMGIootXpAa0A8LGrgXofikR8UDqC8R0aUxIxCLg6
8U14Ap1GK9crm6/T7dirhkpwXviW9OXps7dFF0mSfvKaAUmdN+QS3HYLmnI+TNv2G5YKOb+P
IT0SEGDGvf7TN0se99FWiAipL6N6SepN9lCJPJSUzo80bspPrHoH9ZSxrD+itXi7jVhT3nGr
f+RMqJVx8buw9jKrTykFHoO3qFJHpbuCeW3khVKQPE5liEXB3+1hWzmSAnF/D5PiW26Fdy6p
QhBxgQMiiTWzR6CUf/lFHzpGPbKPpW6GzKidAAAAAAAA
--------------ms000900000908040105010106--



From owner-ietf-calendar@mail.imc.org  Thu Sep 26 12:07:56 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13199
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 12:07:55 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QFoYb17953
	for ietf-calendar-bks; Thu, 26 Sep 2002 08:50:34 -0700 (PDT)
Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QFoXv17949
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 08:50:33 -0700 (PDT)
Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV 
          with ESMTP; Thu, 26 Sep 2002 16:50:27 +0100
Received: from ecemm (helo=localhost)	by mail.ilrt.bris.ac.uk 
          with local-esmtp (Exim 3.16 #1)	id 17uarX-0000Xj-00	for ietf-calendar@imc.org;
          Thu, 26 Sep 2002 16:47:35 +0100
Date: Thu, 26 Sep 2002 16:47:35 +0100 (BST)
From: Libby Miller <Libby.Miller@bristol.ac.uk>
X-X-Sender: ecemm@mail.ilrt.bris.ac.uk
To: ietf-calendar@imc.org
Subject: RDF calendar workshop, Bristol, UK, 2002-10-09
Message-ID: <Pine.GSO.4.44.0209261455270.7017-100000@mail.ilrt.bris.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>



hi,

As part of the SWAD-Europe project[1] we are holding a series of
developer workshops on various topics. The next workshop is going to be
about the Semantic Web and calendaring, and will be held in Bristol, UK
on 9th October 2002. Everyone with an interest in RDF and calendaring is
welcome, although numbers are limited.

Event homepage:
http://www.w3.org/2001/sw/Europe/events/200210-cal/

Registration (before 5th October)
http://cgi.w3.org/Register/selectUser.pl?_w3c_meetingName=swad200210cal

Aims:
* to describe usecases for an RDF calendar vocabulary (for example
compatibility with iCalendar, combining other information
with calendar information [2], reasoning, events as an idiom for
describing how things change over time)
* to identify an RDF calendar vocabulary for the usecases
* to identify issues in conversion (for example timezones, repeating
events, date time formats, simplicity, round tripping from iCalendar)

cheers

Libby

[1] http://www.w3.org/2001/sw/Europe/
[2] http://lists.w3.org/Archives/Public/www-rdf-calendar/2002Sep/0014.html

















From owner-ietf-calendar@mail.imc.org  Thu Sep 26 12:54:36 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14834
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 12:54:35 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QGjXQ21722
	for ietf-calendar-bks; Thu, 26 Sep 2002 09:45:33 -0700 (PDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QGjWv21716
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 09:45:32 -0700 (PDT)
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QGjTN06503
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 09:45:29 -0700 (PDT)
Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QGjRl06473;
	Thu, 26 Sep 2002 09:45:27 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8QGjOG26483;
	Thu, 26 Sep 2002 10:45:26 -0600 (MDT)
Message-ID: <3D9339A3.85973BD9@oracle.com>
Date: Thu, 26 Sep 2002 12:45:23 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: Bruce_Kahn@notesdev.ibm.com
CC: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <OF13C46DD4.9DED39EC-ON85256C3F.0052AD8E-85256C3F.0057C685@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Georged replied on 09/13/2002 10:51:56 AM:
> >   Shouldn't the CUA be able to detect that an event has a large
> > inline attachment, and decide not to get the attachment but get
> > the rest of the event? Or if the attachment is too big for
> > the CUA, the attachment is not returned?
> 
> [Product deathmarches have a way of causing WG neglect so I appologize in advance if this is already been covered...]
> 
> We have no way to detect that kind of info in CAP last time I dived deep.  Nor do we have any way to indicate this to the CS (or of the CS to indicate on the returend data "I would have sent you the
> 2 ATTACHments but they were both bigger than the size you said was your max allowed size.")

  Yes, but it would be nice if we did have such a feature.

> 
> >                                            The CUA can display a
> > message to the CU that the attachment was too big to download.
> 
> Perhaps you are thinking of IMAP where the MUA can retrieve the body structure of the message and then load down the parts it wants/needs...  We dont have that in CAP though (although I think Pete
> put it in ICAP a few years ago...).

  I was thinking of being able to do it in CAP if we had the above mentioned
feature.

> 
> > Should the CU not be able to see the event because the attachment
> > is too big?
> 
> No.  If the CUA cant handle ATTACHments then it should not ask for them.

  What if the CUA can only handle attachments up to a certain size?

> 
> It would be poor CUA design to NOT download, say, a meeting for today just because my Palm does not have the space for the mongo attachment.  That would make me think that I was free at that time
> slot when in fact Im not and I would miss my meeting.

  Then the CUA should somehow be able to detect that it should
not try to download the attachment because it is too big.

> 
> >   An inline attachment can easily get very big, especially, if the
> > CUA does not support multipart.
> 
> That is why the _intended_ use of the inline ATTACHment is for SMALL ATTACHments.  It would be considered an abuse to inline the 5.8M PowerPoint presentation although its unspecifed exactly how
> "small" small is.  Common sense should be applied here.
> 
> >                                 However, how often can a DESCRIPTION,
> > SUMMARY, number of ATTENDEES, etc., be bigger than the maximum? What
> > would a typical maximum be? 1K, 10K, 100K?
> 
> With regard to properties that you need to make the entry meaningfull (ie: SUMMARY, DESCRIPTION) where there can be ALTREPs the story is a bit different.  We have never put a limit on their size but
> we (collectively) expected that SUMMARY is the short text that describes the event (ie: the Subject line in the iMIP message or that is rendered in the 'view' of the calendar that a CU sees such as
> in Organizer, Outlook, etc.)  The DESCRIPTION property is "a more complete description" than what you find in SUMMARY.  This is typically the bigger, more complex information (much like the body of
> an email vs the Subject line).
> 
> There is no limit to their sizes or to the size of the ALTREPs.  Nor is there a limit to the complexity of the ALTREPs; they can be single MIME elements (ie: text/html) or multipart elements
> themselves (ie: multipart/alternative with text/html, application/ms-tnef and application/postscript subelements) but thats a sidenote really....
> 
> The properties like SUBJECT or DESCRIPTION are necessary to properly present the entry to the CU in some fashion.  If they are missing then the entry is probably not very meaningful ("Hmm, George
> invited me to an event but he didnt send any Summary or detailed info about it...").  If the ATTACHment was missing then at least I know something about the entry ("Hmm, George invited me to discuss
> the CAP design for multiparts and ATTACHments...") so I can make a more informed choice as to what to do.
> 
> All this begs the question: Why does it matter what a typical size for something is?  Hopefully you aren't designing anything (CAP or CAP engine) so that there are hard limits...

  This question came up when discussing if a parameter that limits
the size of an iCalendar is sufficient to prevent sending iCalendars
with huge attachments to clients that can not support huge attachments.
My point was that a typical iCalendar, without attachments, would be
very small. In contrast attachments can be very big. We probably should
have a parameter to limit the size of the iCalendar and one for
the attachments. If the limit for the attachments would be exceeded
we would still return the event, but with an error message saying
that the attachment(s) could not be sent since they exceeded the limit.

> 
> > > True - I mean - the CUA does it - out of scope for CAP.
> > > The CUA can store the ALTREP or not, but not with CAP.
> 
> [This looks like Dougs response here but I missed it the 1st time around...]
> 
> Whoa!!!!  Why not _with_ CAP??  Ive yet to hear any good reason that a CUA cannot craft an entry that looks (in part) like:
> 
> multipart/related
>     text/calendar (with CID:1.1)
>         ...
>         DESCRIPTION;ALTREP=CID:1.2:Agenda\n1) CAP design review\n...
>         ...
>     text/html (with CID:1.2)
>         <HTML><HEAD><TITLE>CAP Design Review</TITLE></HEAD><BODY>
>         <P><H1>Agenda:</H1><OL><LI>CAP Design</LI>...
> 
> Why cant a CUA send this to a CS using CAP??
> 
> The only reason I can think of is that the choice for a CS's back end storage is some dB engine/model that cant deal with multipart.  Sorry, thats not an acceptable justification to me or my users.
>  We no longer live in 'plain' ASCII email world and users are getting more and more used to richer data so I really really need to hear a very good reason that CAP should NOT support multipart.
> 
> >   Given ATTACHments and ALTREP are there still people out there who
> > think support for multipart should be a MAY? If yes, let us know.
> > (If there are people who say yes, I am fine with keeping it a
> > MAY!)
> 
> I think that MAY is too weak myself given that iCalendar is already 'multipart ready' (TM by me) with ATTACHments and ALTREPs.  I prefer SHOULD since its stronger and Ive yet to hear any reasons why
> we should NOT have multipart support out of the gates.  From 2119:
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.
> 
> and
> 
> 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>   truly optional.  One vendor may choose to include the item because a
>   particular marketplace requires it or because the vendor feels that
>   it enhances the product while another vendor may omit the same item.
>   An implementation which does not include a particular option MUST be
>   prepared to interoperate with another implementation which does
>   include the option, though perhaps with reduced functionality. In the
>   same vein an implementation which does include a particular option
>   MUST be prepared to interoperate with another implementation which
>   does not include the option (except, of course, for the feature the
>   option provides.)
> 
> Given these Id say that supporting multipart definitely falls under "SHOULD" since multipart is NOT something that just 'enhances the product' unless you are coding to 1985 standards.  The concept
> of multipart has been in iCalendar since Day 1 (or maybe 2) and removing it in a followon protocol 4 years later is something that should be carefully weighted and not just (seemingly) arbitrarily
> done.
> 
> Bruce
> ===========================================================================
> Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
> Messaging & Collaboration                 Phone: 978.399.6496
> IBM Software Group                         FAX: and nothing but the FAX...
> Standard disclaimers apply, even where prohibited by law...


From owner-ietf-calendar@mail.imc.org  Thu Sep 26 13:00:43 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15033
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 13:00:42 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QGoqn21965
	for ietf-calendar-bks; Thu, 26 Sep 2002 09:50:52 -0700 (PDT)
Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QGopv21961
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 09:50:51 -0700 (PDT)
Received: from inet-mail2.oracle.com (localhost [127.0.0.1])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QGomc10432
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 09:50:48 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QGolP10402
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 09:50:47 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8QGokO25549
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 10:50:46 -0600 (MDT)
Message-ID: <3D933AE4.FCD48D78@oracle.com>
Date: Thu, 26 Sep 2002 12:50:44 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
CC: ietf-calendar@imc.org
Subject: Multipart a MUST or a SHOULD [Was: Re: Proposal about multipart etc]
References: <OF13C46DD4.9DED39EC-ON85256C3F.0052AD8E-85256C3F.0057C685@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



We can even make it a MUST. Lately, I have only seen people
who think it should be a SHOULD or a MUST. I propose we change
it unless someone objects. Any objectors?

George

Bruce_Kahn@notesdev.ibm.com wrote:
> 
> >   Given ATTACHments and ALTREP are there still people out there who
> > think support for multipart should be a MAY? If yes, let us know.
> > (If there are people who say yes, I am fine with keeping it a
> > MAY!)
> 
> I think that MAY is too weak myself given that iCalendar is already 'multipart ready' (TM by me) with ATTACHments and ALTREPs.  I prefer SHOULD since its stronger and Ive yet to hear any reasons why
> we should NOT have multipart support out of the gates.  From 2119:
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.
> 
> and
> 
> 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>   truly optional.  One vendor may choose to include the item because a
>   particular marketplace requires it or because the vendor feels that
>   it enhances the product while another vendor may omit the same item.
>   An implementation which does not include a particular option MUST be
>   prepared to interoperate with another implementation which does
>   include the option, though perhaps with reduced functionality. In the
>   same vein an implementation which does include a particular option
>   MUST be prepared to interoperate with another implementation which
>   does not include the option (except, of course, for the feature the
>   option provides.)
> 
> Given these Id say that supporting multipart definitely falls under "SHOULD" since multipart is NOT something that just 'enhances the product' unless you are coding to 1985 standards.  The concept
> of multipart has been in iCalendar since Day 1 (or maybe 2) and removing it in a followon protocol 4 years later is something that should be carefully weighted and not just (seemingly) arbitrarily
> done.
> 
> Bruce
> ===========================================================================
> Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
> Messaging & Collaboration                 Phone: 978.399.6496
> IBM Software Group                         FAX: and nothing but the FAX...
> Standard disclaimers apply, even where prohibited by law...


From owner-ietf-calendar@mail.imc.org  Thu Sep 26 13:23:11 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15710
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 13:23:10 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QHABK23001
	for ietf-calendar-bks; Thu, 26 Sep 2002 10:10:11 -0700 (PDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QHA9v22996
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 10:10:09 -0700 (PDT)
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QHA6N08731
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 10:10:06 -0700 (PDT)
Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QHA6l08717;
	Thu, 26 Sep 2002 10:10:06 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8QHA2G02344;
	Thu, 26 Sep 2002 11:10:04 -0600 (MDT)
Message-ID: <3D933F68.402D1BAC@oracle.com>
Date: Thu, 26 Sep 2002 13:10:00 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: Bruce_Kahn@notesdev.ibm.com
CC: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <OF1F89B418.514E7881-ON85256C3F.005D0B0E-85256C3F.005F44D7@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



I like the idea, see comments below...

Bruce_Kahn@notesdev.ibm.com wrote:
> 
> Doug wrote on 09/12/2002 03:50:38 PM CST:
> > If the endpoint does not want large iCalendar objects, it is
> > free to set its size CAPABILITY to an acceptable limit. However
> > if it is set to unlimited size, then the endpoint is saying that
> > it *is* acceptable.
> 
> I think there is a difference between what is the maximum size object (ie: VEVENT) that a CUA/CS wants and the maximum size non-inlined ATTACHment or ALTREP data.  I for one would definitely NOT
> like to 'miss' a meeting because the large ATTACHment was over some limit when the actual VEVENT size is not.  This is poor design if that can happen!  Then again, if the CUA is pressed for space,
> it should consider NOT asking for ATTACHments...
> 
> In Draft 09b the relevant text is:
> 
>       MAX-COMPONENT-SIZE
>                        1     A positive integer value that specifies
>                              the size of the largest iCalendar
>                              object that the server will accept in
>                              octets. Objects larger than this will be
>                              rejected. The absence of this attribute
>                              indicates no limit. This is also the
>                              maximum value of any BEEP payload
>                              the CS will accept or send.
> 
> This is talking about an "iCalendar object" which does NOT necessarily include the related MIME body parts in a multipart stream.  This could relate to ATTACHments if they are inlined but this does
> NOT cover the size of ALTREPs (at least not as currently written).  Perhaps a MAX-ATTACHMENT-SIZE is necessary as well... (Would it be per ATTACHment or total?  I can see either side as being

  We can even have a MAX-PROPERTY-SIZE ...

> valid...)
> 
> A new MAX-ATTACHMENT-SIZE would not cover any ALTREPs though so should they be folded into the MAX-COMPONENT-SIZE text or should we have another way to limit their size.  Since ALTREP can be added
> to several properties (including TBD ones from SKiCAL, etc) Im inclined to NOT factor them into the MAX-COMPONENT-SIZE.  Rather a something like a MAX-EXTERNAL-SIZE could be created to cover the
> largest size for all 'external' (to the iCalendar object yet still in the MIME stream)...
> 
> Also, if we adopt a MAX-ATTACHMENT-SIZE then we need to be explicit in how an inlined ATTACHment is factored into the octet counts: does it go under MAX-COMPONENT-SIZE or under MAX-ATTACHMENT-SIZE.
>  I for one would say that if its inlined then its under MAX-COMPONENT-SIZE and NOT under MAX-ATTACHMENT-SIZE...

  For inlined, we may want it under MAX-ATTACHMENT-SIZE. We may simply not
return the attachment, but still return the component, with an error letting
us know that the attachment was not sent because it was too big.

> 
> > I think you got off of the path here, which was: *Only* when the
> > other endpoint can not do multipart. If the other endpoint can
> > do multipart, then multipart IS acceptable and no conversion
> > to inline is needed.
> 
> Ok, just to be crytal clear on this (in case we actually draft up some text to cover it at some point): SHOULD/MUST the CS inline ATTACHments ONLY if the requestor is NOT multipart savy and has
> requested non-inlined ATTACHments?  Can the CS do the non-inline -> inline conversion at its whim or only for the non-multipart case.  That is, if I send multipart data to a multipart savy CS, will
> the CS have the option to inline the ATTACHments I send when I turn around and retrieve them back?  Or MUST it preserve the structure whenver possible?
> 
> I think we are in very close agreement on this and I have a bunch of other WG backlog to get thru but Im trying to avoid any vagueness on this in CAP so we dont have a repeat of the multipart pains
> from iCalendar.
> 
> Bruce
> ===========================================================================
> Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
> Messaging & Collaboration                 Phone: 978.399.6496
> IBM Software Group                         FAX: and nothing but the FAX...
> Standard disclaimers apply, even where prohibited by law...

George


From owner-ietf-calendar@mail.imc.org  Thu Sep 26 14:09:17 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16784
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 14:09:16 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QHxNG25434
	for ietf-calendar-bks; Thu, 26 Sep 2002 10:59:23 -0700 (PDT)
Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QHxLv25430
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 10:59:22 -0700 (PDT)
Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50])
	by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g8QHxA5f031839;
	Thu, 26 Sep 2002 19:59:20 +0200
Date: Thu, 26 Sep 2002 19:59:06 +0200
Subject: Re: Proposal about multipart etc
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: Bruce_Kahn@notesdev.ibm.com, ietf-calendar@imc.org
To: George Babics <george.babics@oracle.com>
From: Andrea Campi <a.campi@inet.it>
In-Reply-To: <3D933F68.402D1BAC@oracle.com>
Message-Id: <A6884F98-D179-11D6-B2B3-003065A8EEFC@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



On Thursday, September 26, 2002, at 07:10 PM, George Babics wrote:
>> Also, if we adopt a MAX-ATTACHMENT-SIZE then we need to be explicit 
>> in how an inlined ATTACHment is factored into the octet counts: does 
>> it go under MAX-COMPONENT-SIZE or under MAX-ATTACHMENT-SIZE.
>>  I for one would say that if its inlined then its under 
>> MAX-COMPONENT-SIZE and NOT under MAX-ATTACHMENT-SIZE...
>
>   For inlined, we may want it under MAX-ATTACHMENT-SIZE. We may simply 
> not
> return the attachment, but still return the component, with an error 
> letting
> us know that the attachment was not sent because it was too big.

I agree with Bruce here - it should be under MAX-COMPONENT-SIZE and NOT 
under MAX-ATTACHMENT-SIZE. The rationale is that we want to know that 
we either get a component with the same content as was stored, or we 
get back an error - we don't want to get a partial component with an 
error state.

Besides, what would happen if we had:

attachment #1	50KB
attachment #2	100KB
attachment #3	1.1MB
altrep	  #1	10KB
altrep	  #2   100KB

and a limit of 150KB? We'd need enough details in the error to know 
what we lost, or it wouldn't be very useful...

Bye,
	Andrea



From owner-ietf-calendar@mail.imc.org  Thu Sep 26 14:14:42 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16977
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 14:14:41 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QHrmE25244
	for ietf-calendar-bks; Thu, 26 Sep 2002 10:53:48 -0700 (PDT)
Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QHrlv25240
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 10:53:47 -0700 (PDT)
Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50])
	by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g8QHrf5f030930;
	Thu, 26 Sep 2002 19:53:42 +0200
Date: Thu, 26 Sep 2002 19:53:38 +0200
Subject: Re: Multipart a MUST or a SHOULD [Was: Re: Proposal about multipart etc]
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ietf-calendar@imc.org
To: George Babics <george.babics@oracle.com>
From: Andrea Campi <a.campi@inet.it>
In-Reply-To: <3D933AE4.FCD48D78@oracle.com>
Message-Id: <E2BC417B-D178-11D6-B2B3-003065A8EEFC@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



On Thursday, September 26, 2002, at 06:50 PM, George Babics wrote:
>
> We can even make it a MUST. Lately, I have only seen people
> who think it should be a SHOULD or a MUST. I propose we change
> it unless someone objects. Any objectors?

I object to this. It would be fine having a SHOULD.

Let me quote Bruce:

> multipart/related
>     text/calendar (with CID:1.1)
>         ...
>         DESCRIPTION;ALTREP=CID:1.2:Agenda\n1) CAP design review\n...
>         ...
>     text/html (with CID:1.2)
>         <HTML><HEAD><TITLE>CAP Design Review</TITLE></HEAD><BODY>
>         <P><H1>Agenda:</H1><OL><LI>CAP Design</LI>...
>
> Why cant a CUA send this to a CS using CAP??

I agree no real implementation of a CS would want to refuse this. 
Rather, the problem I see is the opposite. I can foresee a whole class 
of lightweight CUAs which will never send such complex objects, and 
would be greatly complicated if they HAD to implement a parser for 
multipart responses:

  - a CGI based "CUA" for reading agendas (think meetings for a user 
groups, baseball team matches, or look at how Apple iCal publishes 
agendas);
  - a WAP based CUA, be it read only or read/write;
  - even a J2ME CUA for today's mobile phones doesn't have a lot of 
memory at hand.

To these CUAs multipart is not very useful, and actually adds a lot of 
complexity for no benefit.

What's the reason you prefer MUST instead of SHOULD? Is there something 
my proposal for autonegotiating multipart support didn't address? 
Admittedly, it would add a small complexity, but IMHO it's minor 
compared to other parts.

Bye,
	Andrea



From owner-ietf-calendar@mail.imc.org  Thu Sep 26 14:15:41 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17016
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 14:15:40 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QHwK425396
	for ietf-calendar-bks; Thu, 26 Sep 2002 10:58:20 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QHwIv25390
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 10:58:18 -0700 (PDT)
Received: from Royer.com (mail.docutechcorp.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8QHwJR2027739
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 10:58:19 -0700
Message-ID: <3D9347BE.6090607@Royer.com>
Date: Thu, 26 Sep 2002 11:45:34 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Multipart a MUST or a SHOULD [Was: Re: Proposal about multipart
 etc]
References: <OF13C46DD4.9DED39EC-ON85256C3F.0052AD8E-85256C3F.0057C685@iris.com> <3D933AE4.FCD48D78@oracle.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040401020802000409030909"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms040401020802000409030909
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Are you asking that it be a MUST for all valid multipart types?
(multipart/related, multipart/alternate, multipart/mixed, ...)
Which would include nested multi parts (a multipart alternate
body part that contains a multipart related mime object, ...)?

I would like to see it a MUST for multipart support.

Then we can extend/modify the size capabilities to help
storage and/or bandwidth limited CS's and CUA's.

George Babics wrote:
> 
> We can even make it a MUST. Lately, I have only seen people
> who think it should be a SHOULD or a MUST. I propose we change
> it unless someone objects. Any objectors?
> 
> George
> 
> Bruce_Kahn@notesdev.ibm.com wrote:
> 
>>>  Given ATTACHments and ALTREP are there still people out there who
>>>think support for multipart should be a MAY? If yes, let us know.
>>>(If there are people who say yes, I am fine with keeping it a
>>>MAY!)
>>
>>I think that MAY is too weak myself given that iCalendar is already 'multipart ready' (TM by me) with ATTACHments and ALTREPs.  I prefer SHOULD since its stronger and Ive yet to hear any reasons why
>>we should NOT have multipart support out of the gates.  From 2119:
>>
>>3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>>  may exist valid reasons in particular circumstances to ignore a
>>  particular item, but the full implications must be understood and
>>  carefully weighed before choosing a different course.
>>
>>and
>>
>>5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>>  truly optional.  One vendor may choose to include the item because a
>>  particular marketplace requires it or because the vendor feels that
>>  it enhances the product while another vendor may omit the same item.
>>  An implementation which does not include a particular option MUST be
>>  prepared to interoperate with another implementation which does
>>  include the option, though perhaps with reduced functionality. In the
>>  same vein an implementation which does include a particular option
>>  MUST be prepared to interoperate with another implementation which
>>  does not include the option (except, of course, for the feature the
>>  option provides.)
>>
>>Given these Id say that supporting multipart definitely falls under "SHOULD" since multipart is NOT something that just 'enhances the product' unless you are coding to 1985 standards.  The concept
>>of multipart has been in iCalendar since Day 1 (or maybe 2) and removing it in a followon protocol 4 years later is something that should be carefully weighted and not just (seemingly) arbitrarily
>>done.
>>
>>Bruce
>>===========================================================================
>>Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
>>Messaging & Collaboration                 Phone: 978.399.6496
>>IBM Software Group                         FAX: and nothing but the FAX...
>>Standard disclaimers apply, even where prohibited by law...
> 


--------------ms040401020802000409030909
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkyNjE3NDUzNFowIwYJKoZIhvcNAQkEMRYEFDOsDMbC
XMGP3CHgH2WQuB4xlIZnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBA4k/SmNLaKQTKbyaF
c0WcVufhKBIrP2ERk90YFTT6fms/dV3wmtDADZ7cu79jlYYrV/z3yUsYCr0XRPDA8u+BhlUR
yHQ7GbtRe7aQMc3IkRg8mntwaHsyB4Wy9BeYiEo5VniAFj9pLqgdCnVDEwdXYuHpeJPQ7Xv4
5aDuiqmrBQrfkx1T87ruP40zbS7zwhPTGuerj9wnvl3q5Zwd228VHx8s77LD7ILid1teZDaK
wjyRq14KonaE0M4UpkyTSQlOL+am34/b7PVwRLSFQb42vY7KwypPPDauT6MIm/yhK63tGBw+
NN5yC4iYCSLntmlsrNXo3TK+n/lQV/MMOMTVAAAAAAAA
--------------ms040401020802000409030909--



From owner-ietf-calendar@mail.imc.org  Thu Sep 26 14:31:27 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17479
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 14:31:27 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QILNj25928
	for ietf-calendar-bks; Thu, 26 Sep 2002 11:21:23 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QILLv25923
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 11:21:21 -0700 (PDT)
Received: from Royer.com (mail.docutechcorp.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8QILMR2027919
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 11:21:23 -0700
Message-ID: <3D934D26.2080506@Royer.com>
Date: Thu, 26 Sep 2002 12:08:38 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <OF1F89B418.514E7881-ON85256C3F.005D0B0E-85256C3F.005F44D7@iris.com> <3D933F68.402D1BAC@oracle.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000601070808000001030008"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms000601070808000001030008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


SIZE: It makes no difference if an attachment is inline or a body part,
as the endpoint can simply rewrite the object.

So, how about only these two:

	MAX-OBJECT-SIZE is the entire object size and includes
                         all mime body parts including all headers.

	MAX-BODYPART-SIZE could be for all NON-iCalendar objects. Meaning
                           that this is the max BLOB size that the endpoint
                           can handle outside of an iCalendar object.

	And maybe:


	MAX-COMPONENT-SIZE, Which only includes everything between
  		            the first BEGIN: and the last END:

And all -SIZE capabilities are in over the wire size. So if BASE64
encoding doubles the size of the object, then the capability specifies
the over the wire doubled size even when it could be stored in a
much smaller binary size.


--------------ms000601070808000001030008
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkyNjE4MDgzOFowIwYJKoZIhvcNAQkEMRYEFHOkY4vn
fEgHMgYiAd6dZIgGtOv8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQC/eKxXhceyiSMUv1oe
fNlqoR5Y529BJ4orEKwydp4QEThjWL3DG2iFvihCsShJdko+2WXwvszj6DZpghXoyT1D48h/
hEVlc+G0fDGwmn/2bVojZtQl1KoZXP0MvUCKwc4P0rbfRHSal3t9zKoXOuPFORG9Uk+miGjg
VUBkhsQdvcTEnafhPZ7NvdV3WU0SH5FWLe6Y5+MDV2+HX79iYqeO8pwcoz6ud2sV6QIL76hg
CmS/fL1+llo4QkVJW4CdnXnEqhXTu7xW/R2E/+keGj7T18UP0VeMejjSbhhs40gTcNGnpScz
x1PmZX0jcg2E4bC37URw6q0McpfcfC/itDdqAAAAAAAA
--------------ms000601070808000001030008--



From owner-ietf-calendar@mail.imc.org  Thu Sep 26 14:54:16 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18157
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 14:54:15 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QIh1X27124
	for ietf-calendar-bks; Thu, 26 Sep 2002 11:43:01 -0700 (PDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QIh0v27120
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 11:43:00 -0700 (PDT)
Received: from inet-mail3.oracle.com (localhost [127.0.0.1])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QIguP06977
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 11:42:56 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QIguR06955
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 11:42:56 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8QIgtv29814
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 12:42:55 -0600 (MDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8QIgrf29768;
	Thu, 26 Sep 2002 12:42:53 -0600 (MDT)
Message-ID: <3D93552B.41289109@oracle.com>
Date: Thu, 26 Sep 2002 14:42:51 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: Andrea Campi <a.campi@inet.it>
CC: ietf-calendar@imc.org
Subject: Re: Multipart a MUST or a SHOULD [Was: Re: Proposal about multipart etc]
References: <E2BC417B-D178-11D6-B2B3-003065A8EEFC@inet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Andrea Campi wrote:
> 
> On Thursday, September 26, 2002, at 06:50 PM, George Babics wrote:
> >
> > We can even make it a MUST. Lately, I have only seen people
> > who think it should be a SHOULD or a MUST. I propose we change
> > it unless someone objects. Any objectors?
> 
> I object to this. It would be fine having a SHOULD.
> 
> Let me quote Bruce:
> 
> > multipart/related
> >     text/calendar (with CID:1.1)
> >         ...
> >         DESCRIPTION;ALTREP=CID:1.2:Agenda\n1) CAP design review\n...
> >         ...
> >     text/html (with CID:1.2)
> >         <HTML><HEAD><TITLE>CAP Design Review</TITLE></HEAD><BODY>
> >         <P><H1>Agenda:</H1><OL><LI>CAP Design</LI>...
> >
> > Why cant a CUA send this to a CS using CAP??
> 
> I agree no real implementation of a CS would want to refuse this.
> Rather, the problem I see is the opposite. I can foresee a whole class
> of lightweight CUAs which will never send such complex objects, and
> would be greatly complicated if they HAD to implement a parser for
> multipart responses:
> 
>   - a CGI based "CUA" for reading agendas (think meetings for a user
> groups, baseball team matches, or look at how Apple iCal publishes
> agendas);
>   - a WAP based CUA, be it read only or read/write;
>   - even a J2ME CUA for today's mobile phones doesn't have a lot of
> memory at hand.
> 
> To these CUAs multipart is not very useful, and actually adds a lot of
> complexity for no benefit.
> 
> What's the reason you prefer MUST instead of SHOULD? Is there something
> my proposal for autonegotiating multipart support didn't address?
> Admittedly, it would add a small complexity, but IMHO it's minor
> compared to other parts.

  A MUST would be preferable instead of a SHOULD because
there would only be one way to do it, and this may help
interoperability. Furthermore, it will remove some complexity.

  However, given the concerns for lightweight CUAs are more
important, I am fine with SHOULD.

> 
> Bye,
>         Andrea

George


From owner-ietf-calendar@mail.imc.org  Thu Sep 26 14:55:25 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18204
	for <calsch-archive@lists.ietf.org>; Thu, 26 Sep 2002 14:55:24 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8QIlEC27295
	for ietf-calendar-bks; Thu, 26 Sep 2002 11:47:14 -0700 (PDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QIlEv27289
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 11:47:14 -0700 (PDT)
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QIlA720233
	for <ietf-calendar@imc.org>; Thu, 26 Sep 2002 11:47:11 -0700 (PDT)
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8QIl9p20196;
	Thu, 26 Sep 2002 11:47:09 -0700 (PDT)
Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172])
	by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8QIl8r11847;
	Thu, 26 Sep 2002 12:47:08 -0600 (MDT)
Message-ID: <3D93562A.74534D4A@oracle.com>
Date: Thu, 26 Sep 2002 14:47:06 -0400
From: George Babics <george.babics@oracle.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr-CA
MIME-Version: 1.0
To: Andrea Campi <a.campi@inet.it>
CC: Bruce_Kahn@notesdev.ibm.com, ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <A6884F98-D179-11D6-B2B3-003065A8EEFC@inet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Andrea Campi wrote:
> 
> On Thursday, September 26, 2002, at 07:10 PM, George Babics wrote:
> >> Also, if we adopt a MAX-ATTACHMENT-SIZE then we need to be explicit
> >> in how an inlined ATTACHment is factored into the octet counts: does
> >> it go under MAX-COMPONENT-SIZE or under MAX-ATTACHMENT-SIZE.
> >>  I for one would say that if its inlined then its under
> >> MAX-COMPONENT-SIZE and NOT under MAX-ATTACHMENT-SIZE...
> >
> >   For inlined, we may want it under MAX-ATTACHMENT-SIZE. We may simply
> > not
> > return the attachment, but still return the component, with an error
> > letting
> > us know that the attachment was not sent because it was too big.
> 
> I agree with Bruce here - it should be under MAX-COMPONENT-SIZE and NOT
> under MAX-ATTACHMENT-SIZE. The rationale is that we want to know that
> we either get a component with the same content as was stored, or we
> get back an error - we don't want to get a partial component with an
> error state.
> 
> Besides, what would happen if we had:
> 
> attachment #1   50KB
> attachment #2   100KB
> attachment #3   1.1MB
> altrep    #1    10KB
> altrep    #2   100KB
> 
> and a limit of 150KB? We'd need enough details in the error to know
> what we lost, or it wouldn't be very useful...

  Why not an error simply stating that some of the attachments could
not be downloaded. A user will still want to see the basic information
about an event even if some of the attachments are too big for his
CUA.

> 
> Bye,
>         Andrea

George


From owner-ietf-calendar@mail.imc.org  Fri Sep 27 07:20:29 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16825
	for <calsch-archive@lists.ietf.org>; Fri, 27 Sep 2002 07:20:29 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8RB9jd22480
	for ietf-calendar-bks; Fri, 27 Sep 2002 04:09:45 -0700 (PDT)
Received: from eeyore.jsoft.com (24-240-234-245.charter.com [24.240.234.245])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8RB9hv22476
	for <ietf-calendar@imc.org>; Fri, 27 Sep 2002 04:09:44 -0700 (PDT)
Received: from jsoft.com (IDENT:KBSswnOktf76Ggt5+dLKTuAB9r5RbPrA@eeyore.jsoft.com [192.168.0.46])
	by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g8RB3RU03517
	for <ietf-calendar@imc.org>; Fri, 27 Sep 2002 06:03:28 -0500
Message-ID: <3D943AFF.2090306@jsoft.com>
Date: Fri, 27 Sep 2002 06:03:27 -0500
From: Gary Frederick <gary.frederick@jsoft.com>
Organization: Jefferson Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Multipart a MUST or a SHOULD [Was: Re: Proposal about multipart
 etc]
References: <OF13C46DD4.9DED39EC-ON85256C3F.0052AD8E-85256C3F.0057C685@iris.com> <3D933AE4.FCD48D78@oracle.com> <3D9347BE.6090607@Royer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Are we getting to

  MUST for multipart support
  adding SIZE* for parts

if so???
  will a CUA can specify what parts it will take?
    can it specify it will not take multipart ever (small device)
    or will it specify individually/ each time

Gary



From owner-ietf-calendar@mail.imc.org  Fri Sep 27 21:41:00 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15756
	for <calsch-archive@lists.ietf.org>; Fri, 27 Sep 2002 21:41:00 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8S1M0A13743
	for ietf-calendar-bks; Fri, 27 Sep 2002 18:22:00 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8S1Lwv13738
	for <ietf-calendar@imc.org>; Fri, 27 Sep 2002 18:21:58 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8S1LoR2010190
	for <ietf-calendar@imc.org>; Fri, 27 Sep 2002 18:21:51 -0700
Message-ID: <3D950122.3040002@Royer.com>
Date: Fri, 27 Sep 2002 19:08:50 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Proposal about multipart etc
References: <A6884F98-D179-11D6-B2B3-003065A8EEFC@inet.it> <3D93562A.74534D4A@oracle.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000509030505090906090503"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms000509030505090906090503
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


>>I agree with Bruce here - it should be under MAX-COMPONENT-SIZE and NOT
>>under MAX-ATTACHMENT-SIZE. The rationale is that we want to know that
>>we either get a component with the same content as was stored, or we
>>get back an error - we don't want to get a partial component with an
>>error state.
>>
>>Besides, what would happen if we had:
>>
>>attachment #1   50KB
>>attachment #2   100KB
>>attachment #3   1.1MB
>>altrep    #1    10KB
>>altrep    #2   100KB
>>
>>and a limit of 150KB? We'd need enough details in the error to know
>>what we lost, or it wouldn't be very useful...
> 
> 
>   Why not an error simply stating that some of the attachments could
> not be downloaded. A user will still want to see the basic information
> about an event even if some of the attachments are too big for his
> CUA.


How about specifying that the endpoint MUST include the error
status and CID (or MID) for all items that could not be transfered
WITH their wire size in octets:

All three could be returned. Starting with attachment #3 in
the example above:

		3.x TOO BIG: 1100000 CID:123
		3.x TOO BIG: 10000 CID:456sdf
		3.x TOO BIG: 100000 CID:sfjjdsf

Then how about we extend CAL-QL and add something like:

		SELECT bodypart('CID:123') FROM VEVENT WHERE UID = 'abc'

And the results would be:

	<multipart/related? mime header>

	<text/calendar mime headers>

	BEGIN:VENENT
	..<needed stuff>..

	(For ATTACH body parts)
	ATTACH:CID:123	

	(and for an ALTREP)
	DESCRIPTION;ALTREP="CID:sfjjdsf":Project description ...

	END:VEVNET

			
	<bodypart 'CID:123' mime headers>
	...data...


		
With the size and the CID, the endpoint could determine for itself
if it wanted to fetch the body part. It would allow for ALTREP
and ATTACH. And if multiple 'bodypart()' functions are supplied, then
the properties and body parts must be in the order specified in the
query.







--------------ms000509030505090906090503
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkyODAxMDg1MFowIwYJKoZIhvcNAQkEMRYEFGuSzPOt
mCJZoVB1Uxv+piwQO7nmMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCE5WadMbXF6mVbDMW3
2HYGRbk15qksfRLacbX3rI7ydl+vIuGmPdt7eeubjF8Q4YRtg8o+W7jEmKnUXX1fL87r6vVK
9p7NeFgMXz612xnlFBdtSTvIBX8l6+dq3btNDqDDSXBsZHcLgpB6GOW1kKkvXKLGXciDs5iI
7uH/V7Q+dT+JSiKGMsEt/FxQepAMpHD4XwBor75SgVafVrCmr1kmk04I5LMFeng3AP+27xLl
Waa3LU+GoB530kz7LTqqSHZGCezsOQP5AUEFuZX2oQF8B6xeKjAf1OpRLdORwfAH/ygFpdak
Rw6ZZKI44Gx78bDhlV0i6CL11RdqI+7TE9y4AAAAAAAA
--------------ms000509030505090906090503--



From owner-ietf-calendar@mail.imc.org  Mon Sep 30 17:04:34 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21559
	for <calsch-archive@lists.ietf.org>; Mon, 30 Sep 2002 17:04:33 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8UKoI111933
	for ietf-calendar-bks; Mon, 30 Sep 2002 13:50:18 -0700 (PDT)
Received: from royer.com (royer.com [4.23.9.161])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8UKoHv11929
	for <ietf-calendar@imc.org>; Mon, 30 Sep 2002 13:50:17 -0700 (PDT)
Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30])
	by royer.com (8.12.2/8.12.2) with ESMTP id g8UKo4R2006970
	for <ietf-calendar@imc.org>; Mon, 30 Sep 2002 13:50:04 -0700
Message-ID: <3D98B5CF.6030601@Royer.com>
Date: Mon, 30 Sep 2002 14:36:31 -0600
From: Doug Royer <Doug@royer.com>
Reply-To: ietf-calendar@imc.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Next version of CAP.TXT
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000004090504000401070209"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a cryptographically signed message in MIME format.

--------------ms000004090504000401070209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


The cutoff date for I-D submissions is approaching.

I will be going through the list to find items that I may
have forgotten that need to be included in the next version.

If anyone has any items, summaries they would like to post
about the discussions we have had, it would be helpful.

Just skimming the subject lines, here are the changes I see
in the next version:


	Multipart implemented in CUA and CS: SHOULD
	
	GET-CAPABILITY: CS - MUST, CUA - SHOULD

	The CAL-QL ABNF needs to be fixed, it does not support
	all of the features.

	QUERYID is unique to VAGENDA.


-- 
-
Doug Royer                       Work: (208)612-INET
Doug@Royer.com                   Fax:  (866)594-8574
http://INET-Consulting.com       Cell: (208)520-4044
http://Royer.com/People/Doug

--------------ms000004090504000401070209
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw
MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD
EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob
cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB
JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx
3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t
VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G
VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ
Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ
PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW
YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM
SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT
KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK
RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO
jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS
qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv
q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf
vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ
JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG
CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC
AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh
c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9
ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU
ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe
jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkzMDIwMzYzMVowIwYJKoZIhvcNAQkEMRYEFAMPiYMD
d8C1xtqyK9ZIWmv/s+zrMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG
9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT
aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk
YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBa7xoIKIF2CTXhuziU
izwx5+9z5k8PyTD55iWp40Q60Lc1qjRWRFZo1sdh+J7tHfnl2ly6zxcc0IudsroHt1pvjVcw
PVKdt6NSPIBqy1Ry5aZa5/RXr+KPLRrgDMfm4+IcgbGqQ6eSTSAaSaAAN4ksOQqewj7snty2
IiI8reMHdpf4shl71X89AGXuEXHXRZkN0EAfB0EXcLjFxtk8cjYlBHO/PfvRQOwEhX+GG76C
QKlb/M8cwf55CbiSxbgDsuzzekkwTXNxWhExs3eznyn1ccOn+YwGJtgdIm0AnJqxHQshhNEf
8O6jQ2XgoLZG7+SRjtBK7Bg7bHwcnr7YB3h0AAAAAAAA
--------------ms000004090504000401070209--