Subject: [Fwd: How To Handle Attachments]

From: George Babics <[email-masked]>
Date: Tue, 10 Sep 2002 11:34:58 -0400

[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: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 11:36:50 -0600

>      up to now many bytes of the old attachment uniquely identifies

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.

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

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

---

From: [email-masked]
Date: Tue, 10 Sep 2002 14:25:47 -0400

>      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"?

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

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.

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

>      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: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: George Babics <[email-masked]>
Date: Tue, 10 Sep 2002 14:34:24 -0400

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

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

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

George

---

From: George Babics <[email-masked]>
Date: Tue, 10 Sep 2002 14:58:51 -0400

[email-masked] wrote:
> 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"?
> 
> 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...
> 
> 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
> 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.
> 
> 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).
> 
> 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: [email-masked]

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 13:58:49 -0600

> ALTREPs, etc)" but perhaps Doug or John can correct me and point this

Correct - We do not have an exclude mechanism.

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

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

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

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

> ATTACHments (inlined or not) and have some way to do this...

Looking for proposals :-)

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 14:14:30 -0600

>       the properties that it wants? Is this sufficient?

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

> and upload another attachment. This can be expensive for inline

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.

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

>   In general, how can we avoid unnecessarily downloading an inline

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:[email-masked]

   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.

---

From: Andrea Campi <[email-masked]>
Date: Wed, 11 Sep 2002 10:24:18 +0200

>       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:[email-masked]
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: George Babics <[email-masked]>
Date: Wed, 11 Sep 2002 09:09:14 -0400

> to the iCalendar object, else it is in another body part, or

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: George Babics <[email-masked]>
Date: Wed, 11 Sep 2002 09:11:12 -0400

Yes, this is the approach I was thinking of taking.

George

---

From: Doug Royer <[email-masked]>
Date: Wed, 11 Sep 2002 10:18:41 -0600

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

---

From: [email-masked]
Date: Wed, 11 Sep 2002 12:39:35 -0400

>   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

---

From: [email-masked]
Date: Wed, 11 Sep 2002 13:14:40 -0400

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

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

> required to be in the CS.

Actually you only allow that for inlined binary:

   order to delete them.

so that does not currently apply to non-inlined ATTACHments.

> way - per the Dallas meeting which formulated the CAP

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???):

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

> 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:<[email-masked]> to ATTACH:cid:<[email-masked]> then what becomes 
of the data at cid:<[email-masked]> and how does the new data get to 

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

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

> for MIME object that are inline or packaged in the same MIME object

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

> 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

---

From: Patrice Lapierre <[email-masked]>
Date: 11 Sep 2002 14:15:13 -0400

> -->NOTE: The current ABNF is busted - we somehow dropped parameters

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: Doug Royer <[email-masked]>
Date: Wed, 11 Sep 2002 12:19:43 -0600

> Actually you only allow that for inlined binary:

Yes - your right.

> so that does not currently apply to non-inlined ATTACHments.

Yep - your right.

> 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

> > order to delete them.  When the CS compares the attachment data it
> > is compared in its binary form.  The ATTACHMENT value supplied by the
> 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.

> 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:<[email-masked]> to
> ATTACH:cid:<[email-masked]> then what becomes of the data at
> cid:<[email-masked]> and how does the new data get to

If you update the component to the new attach value, then
that has nothing to do with the fact that cid:<[email-masked]>
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.

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

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

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

---

From: Doug Royer <[email-masked]>
Date: Wed, 11 Sep 2002 14:16:04 -0600

Patrice Lapierre wrote:
types for all VEVENTs.
> As far as I know parameters were never individually selectable.

You may be right, I thought it was.

> of the DTSTART property but not the value.

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?

---

From: Patrice Lapierre <[email-masked]>
Date: 12 Sep 2002 08:37:44 -0400

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.

---

From: George Babics <[email-masked]>
Date: Thu, 12 Sep 2002 10:38:47 -0400

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

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

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Sep 2002 10:02:15 -0600

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

---

From: [email-masked]
Date: Thu, 12 Sep 2002 14:56:36 -0400

> It would work for inline attachments:

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.

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

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

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

> meant that it had arrived as a body part to the original

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

> do its own garbage collection.

So it sounds like you say the CS should remove the data in 
cid:<[email-masked]>.  If so, we agree once again.  However the CAP draft 
has not text to this effect and it should!

> two after this settles down, I'll add/change text.

Thank you.

> directions of data transfer.

Still not making myself (and George?) clear on this.  The cited text:

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.

> a MID of "OBJECT-1/bp-1", that is valid MIME.

I concur.

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

> > same MIME object/stream (see previous postings for why).

And there was much rejoicing...

> Your right, as soon as I sent the email, I remembered how to

Havent seen it yet but Im still just barely treading water in this latest 
flood of messages...

Bruce

---

From: [email-masked]
Date: Thu, 12 Sep 2002 15:26:38 -0400

>   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

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Sep 2002 14:05:49 -0600

[email-masked] wrote:
> 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

In CAP:

We should change 'to delete them' to 'to delete or modify them' 
Last sentence is going to be deleted.

Would that solve the issue?

---

From: [email-masked]
Date: Thu, 12 Sep 2002 17:30:24 -0400

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

> 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

Correct.

> with the embedded inline ATTACH value.

(We can revisit this when we factor in ALTREPs later...)

> get the contents inline or in another body part (if in the CS).

Yep.  What he said...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Sep 2002 16:03:05 -0600

[email-masked] 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.

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

---

From: [email-masked]
Date: Mon, 16 Sep 2002 16:30:57 -0400

> 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

---

From: Doug Royer <[email-masked]>
Date: Mon, 16 Sep 2002 14:59:13 -0600

[email-masked] wrote:
> 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.

> 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

> entity so explicitly codifying this for all implementors is probably a 

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

---

From: [email-masked]
Date: Wed, 25 Sep 2002 13:45:25 -0400

> Okay - why do I care? :-)

It was your example.  You replied to George:

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: [email-masked]/Part1.3 is used in one VEVENT that already 
exists and you create a new VEVENT that uses 
ATTACH:MID:[email-masked]/Part1.3 then there can be a problem including the 
content of CID:[email-masked]/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...

> body part containing a URI to a MID). 

Thats not what you just said:

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

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Sep 2002 12:46:38 -0600

[email-masked] wrote:
> 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).

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