Subject: Re: New Topic: Export of calendar data and metadata

From: [email-masked]
Date: Wed, 20 Oct 1999 09:55:34 -0400

Maybe I'm missing something here, but should it not be the responsibility 
of the client to ensure that there is an export capability.  It seems to 
me that all we need to declare is that an import/export capability be in 
place.  Maybe we say it needs to be, at a minimum, ASCII format.  But, I 
believe all we need to state is the capability must be there and it is 
handled by the client software.

Doug Royer <[email-masked]>
Sent by: [email-masked]
10/19/99 07:31 PM

        To:     CalSched IETF <[email-masked]>
        cc:     CalSched IETF <[email-masked]>
        Subject:        Re: New Topic: Export of calendar data and metadata

David Madeo wrote:

> ...
> While I can certainly appreciate the complexity of a real moveuser tool, 
I'd
> like to see an agreement on at least the details of an export and import 
of
> a Calendar. I just skimmed the CAP document quickly to look for 
references
> on how to extract not only components, but the calendar properties and 
the
> VCAR's.  While it certainly looks like you can do it, I'd appreciate a
> paragraph explicity explaining what we expect.
> 
> Comments?

Great issue. I have added it as 'W-29 import/export".

I agree with you, it will be needed. Also for calendar synchronization
with disconnected devices. There will need to be a way for a intermediate
tool to pull calendars from 2 or more sources, compare, and perhaps
with a users input - merge. The tool it self is not in scope, but
I think it will be a need that we must address (in addition to
import/export). And I think that import/export will also address
the issue.

I do however remember discussions (I forget the results) where this
was discussed and some problems with supporting synchronization were
deemed out of scope. Just supporting import/export may solve the
issue and address the both needs.

-Doug

---

From: David Madeo <[email-masked]>
Date: Wed, 20 Oct 1999 11:15:54 -0400

[email-masked] wrote:

>
> Maybe I'm missing something here, but should it not be the
> responsibility of the client to ensure that there is an export
> capability.  It seems to me that all we need to declare is that an
> import/export capability be in place.  Maybe we say it needs to be, at
> a minimum, ASCII format.  But, I believe all we need to state is the
> capability must be there and it is handled by the client software.

I'd like to make sure that we define what an "export" is, regardless of
which client you happen to use.     CUA-1 exports just the calendar
data, but not the metadata.  CUA-2 exports both.    I've lost data if
I'm using CUA-1

I don't think this is a new function "EXPORT" or anything, though I'm
interested if others think that is the way to go.  Personally, I suspect
it will be a paragraph explaining what it means to export/import a
calendar, and a list of queries.  The queries will extract a single
calendar with both the calendar data as well as the metadata.  If
everyone uses the same queries, then every product would produce
identical export/import files, which is a good thing.

dmadeo

PS: I'd hope that the servers which export data behind the scenes would
also use the same queries.

---

From: Doug Royer <[email-masked]>
Date: Wed, 20 Oct 1999 11:33:15 -0700

[email-masked] wrote:
> 
> Maybe I'm missing something here, but should it not be the responsibility of
> the client to ensure that there is an export capability.  It seems to me that
> all we need to declare is that an import/export capability be in place.  Maybe
> we say it needs to be, at a minimum, ASCII format.  But, I believe all we need
> to state is the capability must be there and it is handled by the client
> software.

Yes - however we need to make sure that CUA can get ALL of the calendar
information. I can't think of anything they can't get via CAP.

When you move a calendar from ISP-1 to ISP-2, do you keep any, some,
or all of the VCARs? Are UPNs portable? Are VCARs portable? Are
there any other issues?