Subject: Re: [Ietf-caldav] Calendar collections
From: "G. Barnes" <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Thu, 25 Aug 2005 16:34:19 -0700 (PDT)
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

On Thu, 25 Aug 2005, Lisa Dusseault wrote:

> You're both entirely correct, but collections are rather a necessity for many 
> existing architectures.  Some of what you need or want collections for:
> - must have for PROPFIND -- partition entire space of events into 
> reasonable-to-PROPFIND chunks
> - nice to have for managing quota (proposed quota properties on collections)
> - nice to have (or must on some servers) for managing access control -- can 
> grant "read" access to Mike on my calendar via the calendar collection
> - collections inside user accounts provide guidance for ownership -- who 
> should be able to control content as last resort
> - the standard, required way URLs are constructed in WebDAV

As I said, I'm not suggesting the existing data model be changed.
You list some of the good reasons why it is the way it is.

[...]
> Mike, I'm quite sensitive to the comparison to email (we're struggling with 
> that with IMAP support in Chandler).  But unless we had or designed a new 
> collection-free repository access protocol (or morphed WebDAV into one) we're 
> kind of stuck with collections.  I welcome any suggestions that help ensure 
> that the protocol data model isn't forced into user's faces any more than it 
> has to be.

I made one concrete suggestion.  I think the 2nd paragraph in 4.6.1 should
be changed:

    Support for MKCALENDAR on the server is OPTIONAL because some
    calendar stores only support one calendar per user (or principal) and
    those are typically pre-created for each account.  However, servers
    and clients are strongly encouraged to support MKCALENDAR whenever
    possible to allow users to create multiple calendar collections to
    better help organize their data.

First of all, there's the obvious problem that this paragraph says
OPTIONAL (equivalent to MAY), when Section 2 says SHOULD.

More importantly for this discussion:  if you agree that CalDAV 
is not necessarily in the business of defining a user
model, then the justification that MKCALENDAR 'allows users to create
multiple calendar collections to better organize their data' should
not be used, as it closely links the DAV collections model and the user
model.

I originally suggested that the SHOULD (from section 2) be changed into
a MAY.  Upon further reflection, I suspect there are probably good reasons
why we want to encourage support of MKCALENDAR, such as that it
allows *clients* to create calendar collections when appropriate --- if
we're going to force clients to create a coherent user model out of the
WebDAV collections model, we should give them all the tools we can.  So
I withdraw any preference for SHOULD vs. MAY/OPTIONAL, as long as the
justification in the last sentence is changed to make it clear that
this method is for the benefit of CalDAV clients, not the end users.

[...]
> Finally, Greg, part of the problem you describe with different calendar 
> owners wanting a piece of the same public event is inherent not just in 
> WebDAV but in the federated nature of successful content systems on the 
> Internet.  Today if I want to publicize a band's concert I do so on my own 
> Web blog even if that band has it's own web site and the concert hall has its 
> own web site too.  If you send me an email you probably retain a copy on your 
> server as well as the copy (or copies) I retain on my server.  I don't think 
> that single-instancing public content is a problem that we can or want to fix 
> -- and I apologize if this turns out to be a straw man.

I could easily change the example so that it works within
the university setting, where it's easy to imagine most or all of the 
calendars reside on the same server.  But even if you only consider private 
events, partitioning is not easy or, I think, particularly desirable.  If 
there's a retirement party for my co-worker Joe next Friday during regular 
work hours, do I stick that in my 'social' calendar, or my 'work' calendar? 
This goes back to my filing example.  I can divide most of my stuff into 
neat little categories, but some of it belongs in more than one.

                   Greg Barnes
                   Computing and Communications, University of Washington
                   [email-masked]
                   (206) 685-3295

> On Aug 25, 2005, at 8:05 AM, Mike Shaver wrote:
>
>> On 8/25/05, G. Barnes <[email-masked]> wrote:
>>> This discussion reinforces my belief that the data model of CalDAV
>>> calendar collections probably should not be used as the data model one
>>> presents to users.
>>> 
>>> Although this is never stated explicitly in the draft, it appears to
>>> me that the underlying CalDAV model is one where calendar collections
>>> partition the universe of events.  I'm sure there are valid reasons
>>> for this model, so I'm certainly not going to say it should be changed.
>>> 
>>> However, there is a danger when you try to make your users' model match
>>> this model.  That is, I think most people who use calendaring systems
>>> will agree that a 'calendar' is a useful thing to think about.  But
>>> if you try to make 'calendars' equivalent to CalDAV calendar collections,
>>> you're going to run into problems.
>> 
>> Yes, yes, yes.  This is basically what happened with every thick mail
>> client built in the 90s: it was a faithful reflection of the server's
>> folder hierarchy -- or, for many users, the hierarchies of multiple
>> servers.  In the calendar case we already have a large body of
>> evidence indicating that users will aggregate many different calendars
>> into their views of the world, and partitioning them along
>> server-storage lines is not something that I think we should be
>> "baking into" recommendations like the CalDAV spec.
>> 
>> Mike
>
>

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Date: Thu, 25 Aug 2005 15:14:06 -0700
To: Mike Shaver <[email-masked]>
Cc: "G. Barnes" <[email-masked]>, CalDAV DevList <[email-masked]>

You're both entirely correct, but collections are rather a necessity 
for many existing architectures.  Some of what you need or want 
collections for:
  - must have for PROPFIND -- partition entire space of events into 
reasonable-to-PROPFIND chunks
  - nice to have for managing quota (proposed quota properties on 
collections)
  - nice to have (or must on some servers) for managing access control 
-- can grant "read" access to Mike on my calendar via the calendar 
collection
  - collections inside user accounts provide guidance for ownership -- 
who should be able to control content as last resort
  - the standard, required way URLs are constructed in WebDAV

Recall that addresses and the structure of addresses  are both somewhat 
fixed and somewhat arbitrary.  The REPORTs we have so far go a certain 
way towards treating calendar data like it resides in one big component 
soup without arbitrary collections -- e.g. if you put a bunch of 
sports-related calendars, each in an individual collection, all inside 
one parent collection, and support calendar REPORT on the parent 
collection, then a REPORT lets me see events across all those calendars 
with certain filters.

What else can a server do beyond CalDAV and collections?
  - In addition to the structured, collection namespace, the server 
could offer a "soup" namespace -- for example a way to retrieve each 
event by some unique identifier: 
"http://caldav.example.org/uuid/6ba7b814-9dad-11d1-80b4-00c04fd430c8"
  - The server could support additional REPORT or SEARCH tools to allow 
arbitrary access across the repository.

What else can a client do?
  - A client like Apple's iCal is entirely possible - I can subscribe to 
Mike's calendar on Mike's server and Greg's calendar on Greg's server, 
and overlay those calendars with my own (hosted at a third server)
  - A personal calendar client could (and arguably should) put all "my" 
events into a single calendar.  It could also create a second calendar 
only if I, the user, explicitly wanted a separate set of people to 
share a separate set of events with -- a rare, power-user function.
  - A calendar client managing public event calendars could (and 
arguably should) group events for several organizations or venues into 
one CalDAV "calendar" collection and tag those events according to 
venue and group. E.g. the "543 Howard St office" calendar could include 
events for the Gotham, Lilliput and Whoville meeting rooms and for 
OSAF, KEI and Creative Commons organizations -- all in one collection.
  - A calendar client subscribing to public event calendars could browse 
the "543 Howard St office" calendar and then decide only to display (if 
this were the user's choice) those meetings that were tagged with the 
OSAF organization[1]

These are basically examples of what Greg suggests -- that the basic 
CalDAV data model isn't at all the final answer for the client's 
calendar model or the mental model it creates for users.

Mike, I'm quite sensitive to the comparison to email (we're struggling 
with that with IMAP support in Chandler).  But unless we had or 
designed a new collection-free repository access protocol (or morphed 
WebDAV into one) we're kind of stuck with collections.  I welcome any 
suggestions that help ensure that the protocol data model isn't forced 
into user's faces any more than it has to be.

Finally, Greg, part of the problem you describe with different calendar 
owners wanting a piece of the same public event is inherent not just in 
WebDAV but in the federated nature of successful content systems on the 
Internet.  Today if I want to publicize a band's concert I do so on my 
own Web blog even if that band has it's own web site and the concert 
hall has its own web site too.  If you send me an email you probably 
retain a copy on your server as well as the copy (or copies) I retain 
on my server.  I don't think that single-instancing public content is a 
problem that we can or want to fix -- and I apologize if this turns out 
to be a straw man.

Lisa

Footnote 1: I'm hand-waving over the standardization of events tagged 
with organization affiliations or machine-readable locations, because 
we haven't addressed standardizing public calendars --  we're focused 
on individual calendar use cases in CalDAV 1.0.

On Aug 25, 2005, at 8:05 AM, Mike Shaver wrote:

> On 8/25/05, G. Barnes <[email-masked]> wrote:
>> This discussion reinforces my belief that the data model of CalDAV
>> calendar collections probably should not be used as the data model one
>> presents to users.
>>
>> Although this is never stated explicitly in the draft, it appears to
>> me that the underlying CalDAV model is one where calendar collections
>> partition the universe of events.  I'm sure there are valid reasons
>> for this model, so I'm certainly not going to say it should be 
>> changed.
>>
>> However, there is a danger when you try to make your users' model 
>> match
>> this model.  That is, I think most people who use calendaring systems
>> will agree that a 'calendar' is a useful thing to think about.  But
>> if you try to make 'calendars' equivalent to CalDAV calendar 
>> collections,
>> you're going to run into problems.
>
> Yes, yes, yes.  This is basically what happened with every thick mail
> client built in the 90s: it was a faithful reflection of the server's
> folder hierarchy -- or, for many users, the hierarchies of multiple
> servers.  In the calendar case we already have a large body of
> evidence indicating that users will aggregate many different calendars
> into their views of the world, and partitioning them along
> server-storage lines is not something that I think we should be
> "baking into" recommendations like the CalDAV spec.
>
> Mike

Date: Thu, 25 Aug 2005 11:34:57 -0400
From: Cyrus Daboo <[email-masked]>
To: Mike Shaver <[email-masked]>, "G. Barnes" <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Cc: CalDAV DevList <[email-masked]>

Hi Mike,

--On August 25, 2005 11:05:27 AM -0400 Mike Shaver <[email-masked]> 
wrote:

> Yes, yes, yes.  This is basically what happened with every thick mail
> client built in the 90s: it was a faithful reflection of the server's
> folder hierarchy -- or, for many users, the hierarchies of multiple
> servers.  In the calendar case we already have a large body of
> evidence indicating that users will aggregate many different calendars
> into their views of the world, and partitioning them along
> server-storage lines is not something that I think we should be
> "baking into" recommendations like the CalDAV spec.

Currently there is nothing stopping a client from merging data from 
multiple calendar collections into one 'virtual' calendar view. The 
question is whether the 'virtual' calendar view is something that should be 
managed on the server or client end. In the email world (IMAP) clients do 
all the work of virtual mailboxes - which misses one of the major benefits 
of IMAP, namely having the server centrally manage the data in a way 
consistent for all clients. Frankly its about time that IMAP had a virtual 
folder extension. Something similar could be done as an extension to CalDAV 
if the demand arises.

-- 
Cyrus Daboo

Date: Thu, 25 Aug 2005 11:05:27 -0400
From: Mike Shaver <[email-masked]>
To: "G. Barnes" <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Cc: CalDAV DevList <[email-masked]>

On 8/25/05, G. Barnes <[email-masked]> wrote:
> This discussion reinforces my belief that the data model of CalDAV
> calendar collections probably should not be used as the data model one
> presents to users.
>=20
> Although this is never stated explicitly in the draft, it appears to
> me that the underlying CalDAV model is one where calendar collections
> partition the universe of events.  I'm sure there are valid reasons
> for this model, so I'm certainly not going to say it should be changed.
>=20
> However, there is a danger when you try to make your users' model match
> this model.  That is, I think most people who use calendaring systems
> will agree that a 'calendar' is a useful thing to think about.  But
> if you try to make 'calendars' equivalent to CalDAV calendar collections,
> you're going to run into problems.

Yes, yes, yes.  This is basically what happened with every thick mail
client built in the 90s: it was a faithful reflection of the server's
folder hierarchy -- or, for many users, the hierarchies of multiple
servers.  In the calendar case we already have a large body of
evidence indicating that users will aggregate many different calendars
into their views of the world, and partitioning them along
server-storage lines is not something that I think we should be
"baking into" recommendations like the CalDAV spec.

Mike

Date: Wed, 24 Aug 2005 23:02:59 -0700 (PDT)
From: "G. Barnes" <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Cc: CalDAV DevList <[email-masked]>

On Sat, 20 Aug 2005, Lisa Dusseault wrote:

> Yep -- or your administrative interface could offer a way to convert "arts" 
> into a calendar home and move all the events down a level.
>
> I agree that the model limitation imposes drawbacks in the case of certain 
> calendar reorganization use cases.  I just don't think we should optimize for 
> those rare use cases.   Most client implementations will never have to deal 
> with those use cases.

My apologies for jumping in late.

This discussion reinforces my belief that the data model of CalDAV 
calendar collections probably should not be used as the data model one 
presents to users.

Although this is never stated explicitly in the draft, it appears to
me that the underlying CalDAV model is one where calendar collections
partition the universe of events.  I'm sure there are valid reasons
for this model, so I'm certainly not going to say it should be changed.

However, there is a danger when you try to make your users' model match
this model.  That is, I think most people who use calendaring systems
will agree that a 'calendar' is a useful thing to think about.  But
if you try to make 'calendars' equivalent to CalDAV calendar collections,
you're going to run into problems.

To take a simple example, the coffee shop up the hill from my house
is hosting a concert by Joe Smith next Saturday at 6pm.  The coffee shop 
would probably like to add this event to its 'calendar'.  Joe Smith would
probably like to have this event in his 'calendar' of upcoming shows.
The local weekly also wants the event in their 'calendar' of concerts,
and maybe in another 'calendar' of spotlighted events.  While the local
magazine for parents might like to have it in its 'calendar' of kid-friendly
events.  Clearly, these 'calendars' do not partition the universe of
events.

As another example, one can imagine Chemistry 101 has an
associated 'calendar' consisting of all class meetings, plus the
final exam and perhaps some associated study sessions.  But wait, Chem
101 has labs, too, and maybe discussion sections.  But if you're the
professor, you don't show up at the labs or discussion sections, and 
probably not the study session.  So the professor's Chemistry 101
calendar consists of lectures plus the final, plus maybe some deadlines
like when grades have to be turned in and homeworks created.  While
a TA's Chemistry 101 consists mostly of discussion sessions and
labs they lead, and a student's Chem 101 calendar is all the lectures
plus the final and study sessions, plus one lab and one discussion section. 
Meanwhile, the Chemistry department probably wants to create *its* own 
calendar of all the lectures of all the classes in the department, 
including most of these subcalendars.

What I'm getting at is that, as the number of events on your server
increases, your users will want to combine, merge, subdivide, select
and do all sorts of whatnot with them in the ways they like.  And they'll
probably call these things they create 'calendars'.

So I don't think you can just sit back and think the CalDAV model imposes
some small inconveniences in some corner cases.  I suspect it will impose a 
lot of inconveniences a lot of the time, assuming you want your program to 
cater to your users and not vice versa.

On the other hand, I also agree that time is a-wasting, and there's no
point in trying to get the perfect model.  Might as well go with the
limitations that are there now (assuming, of course, the actual 
implementers don't find something wrong with them).

But to reiterate my original point, I think this means the CalDAV model 
cannot be used as a model for users.  You're going to have to build quite 
a lot on top of it to get what users want.

As a tangent, and to get away from the whole 'public events' thing, my 
wife was just complaining to me this weekend that she didn't like my 
filing system for our papers.  Unfortunately, with paper items like bills, 
you have to partition them.  But for events stored on a computer, I think
we can do much better.  Hence all the interest in 'desktop search'.
People can't even organize their own personal files on their
own personal computer in a satisfactory way.  I don't expect
having people partition their personal events is going to work
much better.

To bring this back to something resembling a point, I do have one 
complaint about the draft in light of what I just said, which is with 
4.6.1, MKCALENDAR.  In this section, there is a clear bias toward making 
the CalDAV data model match the real world user model.  For reasons I have 
just argued, I think this is a mistake.  Yes, that's one way of doing 
things, but to imply that it is the best way, as the 2nd paragraph
in this section does, is, I think, wrong.

To put it in IETF terms, I think this paragraph should be changed to
suggest MKCALENDAR as one way to allow people to organize their
events, and the 'SHOULD' in Section 2 should become a 'MAY'.  And now 
that I look at it, Section 2 says MKCALENDAR support is a SHOULD, but 
4.6.1 says it's OPTIONAL.  Regardless of whether you agree with
what I've been saying, these should match.

                   Greg Barnes
                   Computing and Communications, University of Washington
                   [email-masked]
                   (206) 685-3295

> On Aug 20, 2005, at 5:22 PM, Mike Douglass wrote:
>
>> 
>> 
>> Lisa Dusseault wrote:
>> 
>>> ...
>>> I do understand how reorganization can be a problem but I don't see how 
>>> allowing calendar collections to nest would help that case. Can you 
>>> explain that?
>>> 
>> I may have something wrong in my thinking but I see it as mainly a user 
>> convenience issue. Say, for want of a better example, we have 1000 arts 
>> events and we belatedly realised we should have subdivided them so now we 
>> have
>> 
>> arts/event1,... arts/event1000
>> 
>> arts is a calendar collection. We're not allowed to create arts/performance 
>> alongside the events as we would naturally do in a file system. So we have 
>> to do something like rename arts, create a new non-calendar collection and 
>> then create the sub-collections.
>> 
>> The same is presumably true of auser with a personal calendar who may 
>> decide they'd like to subcategorize their personal calendar.
>> 
>> Currently our users can subscribe to "arts" and get all the subcategories 
>> so I will support report on those collections.
>> 
>>> thanks,
>>> Lisa
>>> 
>> 
>> -- 
>> 
>> Mike Douglass                           [email-masked]
>> Senior Systems Programmer
>> Communication & Collaboration Technologies      518 276 6780(voice) 2809
>> (fax)
>> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>> 
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] GET for calendar collections
Date: Mon, 22 Aug 2005 12:57:53 -0700
To: Helge Hess <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

--Apple-Mail-3-404585664
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

On Aug 22, 2005, at 12:42 PM, Helge Hess wrote:

> On 22. Aug 2005, at 21:23 Uhr, Brian Moseley wrote:
>> i did not advocate that it be a requirement, but rather a suggestion, 
>> and a pretty simple one at that.
>
> Yes, but shouldn't CalDAV be kept as tight as possible and focus on 
> the new protocol?
>
>> can you some details about why you don't think caldav should make 
>> this suggestion?
>
> Well, mostly for the same reason why CalDAV doesn't include IMAP4 or 
> LDAP ;-) Separate protocols should be kept separate.
>

I sort of agree with that but we might want to deal with Accept header 
just a little bit -- since we're modeling calendar components as HTTP 
resources, a few words about what to do when the client sends the 
Accept header might be in order.  That doesn't necessarily pull in all 
the other pieces like what to do about PUT which I agree should be a 
separate document -- supporting iCal and CalDAV at the same time, both 
read/write, could be a bite-sized Internet-Draft in itself.  At some 
point Dan Winship was interested in writing such a document but I think 
he's not working on calendar stuff so much now.  Any other volunteers?

lisa
--Apple-Mail-3-404585664
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

On Aug 22, 2005, at 12:42 PM, Helge Hess wrote:

<excerpt>On 22. Aug 2005, at 21:23 Uhr, Brian Moseley wrote:

<excerpt>i did not advocate that it be a requirement, but rather a
suggestion, and a pretty simple one at that.

</excerpt>

Yes, but shouldn't CalDAV be kept as tight as possible and focus on
the new protocol?

<excerpt>can you some details about why you don't think caldav should
make this suggestion?

</excerpt>

Well, mostly for the same reason why CalDAV doesn't include IMAP4 or
LDAP ;-) Separate protocols should be kept separate.

</excerpt>

I sort of agree with that but we might want to deal with Accept header
just a little bit -- since we're modeling calendar components as HTTP
resources, a few words about what to do when the client sends the
Accept header might be in order.  That doesn't necessarily pull in all
the other pieces like what to do about PUT which I agree should be a
separate document -- supporting iCal and CalDAV at the same time, both
read/<bold>write, </bold>could be a bite-sized Internet-Draft in
itself.  At some point Dan Winship was interested in writing such a
document but I think he's not working on calendar stuff so much now. 
Any other volunteers?

lisa
--Apple-Mail-3-404585664--

Date: Mon, 22 Aug 2005 12:57:44 -0700
From: Brian Moseley <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] GET for calendar collections
Cc: CalDAV DevList <[email-masked]>

Helge Hess wrote:

> Anyway if you include that, you'll need to answer at least those  
> questions as well:
> a) PUT?
> b) locking?
> c) ACLs?
> ... with concurrent "real" CalDAV access on the same collection.

with the exception of acls, i don't think any of the rest of 
these concerns are relevant to providing a read-only 
calendar view of a calendar collection.

there has definitely been some noise made about an 
informational document discussing read/write synchronization 
with existing icalendar-over-webdav clients. i'm not 
prepared to go there yet :)

as far as acls go, yes, i think clients would need assurance 
that acls are respected. but let's step back and think about 
what currently happens. i bet 100% of webdav servers return 
text/html directory listings in response to GET requests for 
collections. i also bet that 100% of them respect whatever 
security model they implement when doing so. so i don't see 
acls being problematic here. perhaps the draft authors could 
add whatever language they feel appropriate to what i've 
suggested.

> You don't have access to Google? ;-)
> 
> http://www.google.de/search?as_qdr=all&q=+GET+text%2Fcalendar+site% 
> 3Ahttp%3A%2F%2Flists.osafoundation.org%2Fpipermail%2Fietf-caldav%2F

good one, thanks :)

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] GET for calendar collections
Date: Mon, 22 Aug 2005 21:42:58 +0200
To: CalDAV DevList <[email-masked]>

On 22. Aug 2005, at 21:23 Uhr, Brian Moseley wrote:
> i did not advocate that it be a requirement, but rather a  
> suggestion, and a pretty simple one at that.

Yes, but shouldn't CalDAV be kept as tight as possible and focus on  
the new protocol?

> can you some details about why you don't think caldav should make  
> this suggestion?

Well, mostly for the same reason why CalDAV doesn't include IMAP4 or  
LDAP ;-) Separate protocols should be kept separate.

Anyway if you include that, you'll need to answer at least those  
questions as well:
a) PUT?
b) locking?
c) ACLs?
... with concurrent "real" CalDAV access on the same collection.

>> PS: this was also discussed in the past, you might find the  
>> archives  interesting.
> i bet i would, if i had a viable mechanism for searching the  
> archive other than downloading and grepping the mbox files ;)

You don't have access to Google? ;-)

http://www.google.de/search?as_qdr=all&q=+GET+text%2Fcalendar+site% 
3Ahttp%3A%2F%2Flists.osafoundation.org%2Fpipermail%2Fietf-caldav%2F

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Mon, 22 Aug 2005 12:23:49 -0700
From: Brian Moseley <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] GET for calendar collections

Helge Hess wrote:

> IMO its a separate (/simpler) protocol which can be used alongside  
> CalDAV, just like GroupDAV. So care should be taken that this  protocol 
> can be implemented by the server together with CalDAV (eg  CalDAV should 
> not specify the GET), but it probably doesn't belong  into CalDAV itself 
> and shouldn't be a requirement.

i did not advocate that it be a requirement, but rather a 
suggestion, and a pretty simple one at that.

can you some details about why you don't think caldav should 
make this suggestion?

> PS: this was also discussed in the past, you might find the archives  
> interesting.

i bet i would, if i had a viable mechanism for searching the 
archive other than downloading and grepping the mbox files ;)

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] GET for calendar collections
Date: Mon, 22 Aug 2005 21:09:14 +0200
To: CalDAV DevList <[email-masked]>

On 22. Aug 2005, at 20:53 Uhr, Brian Moseley wrote:
> i wonder if it makes sense for caldav to make the following  
> recommendations:
>
> 1) clients MAY ask for a text/calendar representation of a calendar  
> collection (via the Accept header)
>
> 2) servers SHOULD be able to respond to such a request
>
> in fact, it might be beneficial to recommend text/calendar as the  
> default representation for a calendar collection, for the sake of  
> interoperability with existing clients which expect to be able to  
> GET a single icalendar resource representing an entire calendar.
>
> thoughts?

IMO its a separate (/simpler) protocol which can be used alongside  
CalDAV, just like GroupDAV. So care should be taken that this  
protocol can be implemented by the server together with CalDAV (eg  
CalDAV should not specify the GET), but it probably doesn't belong  
into CalDAV itself and shouldn't be a requirement.

Greets,
   Helge

PS: this was also discussed in the past, you might find the archives  
interesting.
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Mon, 22 Aug 2005 11:53:08 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] GET for calendar collections

as per rfc 2518, the response to a GET request for a 
collection is undefined. perhaps a more natural behavior for 
calendar collections is to return a text/calendar response.

i wonder if it makes sense for caldav to make the following 
recommendations:

1) clients MAY ask for a text/calendar representation of a 
calendar collection (via the Accept header)

2) servers SHOULD be able to respond to such a request

in fact, it might be beneficial to recommend text/calendar 
as the default representation for a calendar collection, for 
the sake of interoperability with existing clients which 
expect to be able to GET a single icalendar resource 
representing an entire calendar.

thoughts?

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Date: Sat, 20 Aug 2005 20:46:57 -0700
To: Mike Douglass <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

Yep -- or your administrative interface could offer a way to convert 
"arts" into a calendar home and move all the events down a level.

I agree that the model limitation imposes drawbacks in the case of 
certain calendar reorganization use cases.  I just don't think we 
should optimize for those rare use cases.   Most client implementations 
will never have to deal with those use cases.

Lisa

On Aug 20, 2005, at 5:22 PM, Mike Douglass wrote:

>
>
> Lisa Dusseault wrote:
>
>> ...
>> I do understand how reorganization can be a problem but I don't see 
>> how allowing calendar collections to nest would help that case. Can 
>> you explain that?
>>
> I may have something wrong in my thinking but I see it as mainly a 
> user convenience issue. Say, for want of a better example, we have 
> 1000 arts events and we belatedly realised we should have subdivided 
> them so now we have
>
> arts/event1,... arts/event1000
>
> arts is a calendar collection. We're not allowed to create 
> arts/performance alongside the events as we would naturally do in a 
> file system. So we have to do something like rename arts, create a new 
> non-calendar collection and then create the sub-collections.
>
> The same is presumably true of auser with a personal calendar who may 
> decide they'd like to subcategorize their personal calendar.
>
> Currently our users can subscribe to "arts" and get all the 
> subcategories so I will support report on those collections.
>
>> thanks,
>> Lisa
>>
>
> -- 
>
> Mike Douglass                           [email-masked]
> Senior Systems Programmer
> Communication & Collaboration Technologies      518 276 6780(voice) 
> 2809
> (fax)
> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>

Date: Sat, 20 Aug 2005 20:22:48 -0400
From: Mike Douglass <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Cc: CalDAV DevList <[email-masked]>

Lisa Dusseault wrote:

> ...
> I do understand how reorganization can be a problem but I don't see 
> how allowing calendar collections to nest would help that case. Can 
> you explain that?
>
I may have something wrong in my thinking but I see it as mainly a user 
convenience issue. Say, for want of a better example, we have 1000 arts 
events and we belatedly realised we should have subdivided them so now 
we have

arts/event1,... arts/event1000

arts is a calendar collection. We're not allowed to create 
arts/performance alongside the events as we would naturally do in a file 
system. So we have to do something like rename arts, create a new 
non-calendar collection and then create the sub-collections.

The same is presumably true of auser with a personal calendar who may 
decide they'd like to subcategorize their personal calendar.

Currently our users can subscribe to "arts" and get all the 
subcategories so I will support report on those collections.

> thanks,
> Lisa
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Date: Sat, 20 Aug 2005 16:22:15 -0700
To: Mike Douglass <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

Hi Mike,

I can't see much of a server implementation difficulty difference 
between allowing calendar collections to contain calendar collections, 
and on the other hand having a parent collection that can contain 
multiple calendar collections.  I guess it does mean that if your 
server allows multiple calendar collections you've got to start the 
user off with a calendar home as well as a starting calendar collection 
-- then they've got a place to make more calendar collections.   If it 
makes it easier the parent collection *can* contain events -- or if it 
makes it easier the parent collection might be disabled for any purpose 
but MKCALENDAR.

Your example of somebody interested in all of "arts" is a great example 
of how somebody can subscribe to a number of calendars.  In that case, 
it would make it easier if the server supported the calendar REPORT 
queries on the "arts" collection as well as on the calendar collections 
inside it.  Then the user would only have to do one REPORT to see all 
the events in the next week.  This is the same way CalDAV does calendar 
roll-up for individual users who have multiple calendars.

I do understand how reorganization can be a problem but I don't see how 
allowing calendar collections to nest would help that case.  Can you 
explain that?

thanks,
Lisa

On Aug 20, 2005, at 1:53 PM, Mike Douglass wrote:

> The first problem I see for personal users is that we rarely know how 
> we
> want to organize our stuff till we've been at it a while.
>
> The current restriction by the way seems to require that we make a 
> users
> top level calendar be inside a (virtual) non-calendar collection
> otherwise they'd never be able to reorganize their events - because 
> they
> can't create a target collection to move their events into. That is - 
> as
> user douglm I can't have a root calendar collection of douglm/ but
> require douglm/calendar
>
> Performance wasn't my concern.
>
> For public events organization is more of a problem. We don't reorg 
> much
> but calendars do provide a way for users to select subsets of events 
> and
> occasionally the need arises. For example we might have:
>
> arts/dance
> arts/film
> arts/theatre
>
> or just
>
> arts/
>
> Somebody may be interested enough in the films to want to subscribe to
> that calendar in their personal calendar but others may be interested 
> in
> all arts events.
>
>
> Lisa Dusseault wrote:
>
>> The way we'd been thinking about multiple nested calendar collections 
>> was that there would have to be some rhyme or reason to why an event 
>> would be in one or the other.
>>
>> If a user has two separate calendar collections, home and work, we 
>> defined what that means -- they really intend the events to be 
>> displayed separately and probably share those two calendars to 
>> separate sets of people (this solves required use cases)
>>
>> But if we have /users/lisa/work, /users/lisa/work/part1 and 
>> /users/lisa/work/part2 then we have a lot of open issues...
>>    * How does the client know whether to put an event in 
>> /users/lisa/work, or in part1 or part2?
>>    * Does it mean something to have part1 and part2?  Are clients 
>> supposed to display any differently depending on where the event is?
>>    * Does the server handle the three collections differently? Or do 
>> they all get included in REPORT? And if they're all in the same 
>> REPORTs then what's the utility of having them split up?
>>    * If the 'work' event collection gets split up, how does that 
>> affect other clients who do synchronization? Can they identify that 
>> an event was the same as the previous and whether it was changed or 
>> not?  (changes might get lost during a reorg, in other words)
>>    * Finally, what use cases does it solve?  How difficult is it if 
>> an event collection grows big?  How big? Can we characterize the 
>> cost?
>>
>> I wouldn't recommend getting users to split their calendar 
>> collections (although note that I may not understand what use case or 
>> problem you have in mind when you describe the user moving 
>> "everything out first")  .  Unless the user decides they really have 
>> two semantically different calendars, all the events for a calendar 
>> really do belong together.  At OSAF we're working with moderately 
>> large 3000-event calendars which is not at all unreasonable to handle 
>> -- and note that Apple iCal performance seems not to suck even 
>> putting all those events in one file.
>>
>> Yes, it's work to enforce the limitation we described, but it's also 
>> work to handle the flexibility.  Work for clients is even worse than 
>> work for servers.  And there's the cost in specification work, 
>> specification complexity and interoperability testing of the various 
>> cases and behaviors.  The tradeoff Bernard and Cyrus and I have 
>> settled on so far did involve considering performance and the other 
>> factors you and I have mentioned.
>>
>> Lisa
>>
>> On Aug 20, 2005, at 1:15 PM, Mike Douglass wrote:
>>
>>> I asked about this but can't find any response:
>>>
>>> Why this restriction? (4.3):
>>>
>>> Calendar collections MUST NOT contain other calendar collections.
>>>
>>> It certainly makes things difficult if my event collection grows big 
>>> and I want to split it up. As a user I have to move everything out 
>>> first before I can create sub-collections.
>>>
>>> It also doesn't correspond to what we expect from most file systems.
>>>
>>> Just interested in knowing before I implement the not insignificant 
>>> amount of code to enforce this.
>>>
>>>
>>> -- 
>>>
>>> Mike Douglass                           [email-masked]
>>> Senior Systems Programmer
>>> Communication & Collaboration Technologies      518 276 6780(voice) 
>>> 2809
>>> (fax)
>>> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>>>
>>> _______________________________________________
>>> Ietf-caldav mailing list -- [email-masked]
>>> See http://ietf.webdav.org/caldav/ for more CalDAV resources
>>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>>
>>
>
> -- 
>
> Mike Douglass                           [email-masked]
> Senior Systems Programmer
> Communication & Collaboration Technologies      518 276 6780(voice) 
> 2809
> (fax)
> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Sat, 20 Aug 2005 15:52:04 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Reply-To: CalDAV DevList <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms010201080805020906000608
Content-Type: multipart/mixed; boundary="------------080503050602040801030002"

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

In addition to Lisa's comments:

	iCalendar does not support nested calendars.

So this would open up for a redesign of iCal at a time
when simplifications and clarifications of iCal are in progress.

The reason iCal does not have nested or layered calendars
has already been discussed on this and the old CALSCH mailing
list. In summary: It causes all kinds of roll-up problems
with busy time, permissions, the reasons Lisa gave, and more.

There is no reason that your user interface can not make calendars
appear nested or layered. iCal does not need to support this feature
in order for your user interface to provide nested views.

Mike Douglass wrote:
> The first problem I see for personal users is that we rarely know how we
> want to organize our stuff till we've been at it a while.
> 
> The current restriction by the way seems to require that we make a users
> top level calendar be inside a (virtual) non-calendar collection
> otherwise they'd never be able to reorganize their events - because they
> can't create a target collection to move their events into. That is - as
> user douglm I can't have a root calendar collection of douglm/ but
> require douglm/calendar
> 
> Performance wasn't my concern.
> 
> For public events organization is more of a problem. We don't reorg much
> but calendars do provide a way for users to select subsets of events and
> occasionally the need arises. For example we might have:
> 

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------080503050602040801030002
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------080503050602040801030002--

--------------ms010201080805020906000608
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010201080805020906000608--

Date: Sat, 20 Aug 2005 16:53:13 -0400
From: Mike Douglass <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections

The first problem I see for personal users is that we rarely know how we
want to organize our stuff till we've been at it a while.

The current restriction by the way seems to require that we make a users
top level calendar be inside a (virtual) non-calendar collection
otherwise they'd never be able to reorganize their events - because they
can't create a target collection to move their events into. That is - as
user douglm I can't have a root calendar collection of douglm/ but
require douglm/calendar

Performance wasn't my concern.

For public events organization is more of a problem. We don't reorg much
but calendars do provide a way for users to select subsets of events and
occasionally the need arises. For example we might have:

arts/dance
arts/film
arts/theatre

or just

arts/

Somebody may be interested enough in the films to want to subscribe to
that calendar in their personal calendar but others may be interested in
all arts events.

Lisa Dusseault wrote:

> The way we'd been thinking about multiple nested calendar collections 
> was that there would have to be some rhyme or reason to why an event 
> would be in one or the other.
>
> If a user has two separate calendar collections, home and work, we 
> defined what that means -- they really intend the events to be 
> displayed separately and probably share those two calendars to 
> separate sets of people (this solves required use cases)
>
> But if we have /users/lisa/work, /users/lisa/work/part1 and 
> /users/lisa/work/part2 then we have a lot of open issues...
>    * How does the client know whether to put an event in 
> /users/lisa/work, or in part1 or part2?
>    * Does it mean something to have part1 and part2?  Are clients 
> supposed to display any differently depending on where the event is?
>    * Does the server handle the three collections differently? Or do 
> they all get included in REPORT? And if they're all in the same 
> REPORTs then what's the utility of having them split up?
>    * If the 'work' event collection gets split up, how does that 
> affect other clients who do synchronization? Can they identify that an 
> event was the same as the previous and whether it was changed or not?  
> (changes might get lost during a reorg, in other words)
>    * Finally, what use cases does it solve?  How difficult is it if an 
> event collection grows big?  How big? Can we characterize the cost?
>
> I wouldn't recommend getting users to split their calendar collections 
> (although note that I may not understand what use case or problem you 
> have in mind when you describe the user moving "everything out 
> first")  .  Unless the user decides they really have two semantically 
> different calendars, all the events for a calendar really do belong 
> together.  At OSAF we're working with moderately large 3000-event 
> calendars which is not at all unreasonable to handle -- and note that 
> Apple iCal performance seems not to suck even putting all those events 
> in one file.
>
> Yes, it's work to enforce the limitation we described, but it's also 
> work to handle the flexibility.  Work for clients is even worse than 
> work for servers.  And there's the cost in specification work, 
> specification complexity and interoperability testing of the various 
> cases and behaviors.  The tradeoff Bernard and Cyrus and I have 
> settled on so far did involve considering performance and the other 
> factors you and I have mentioned.
>
> Lisa
>
> On Aug 20, 2005, at 1:15 PM, Mike Douglass wrote:
>
>> I asked about this but can't find any response:
>>
>> Why this restriction? (4.3):
>>
>> Calendar collections MUST NOT contain other calendar collections.
>>
>> It certainly makes things difficult if my event collection grows big 
>> and I want to split it up. As a user I have to move everything out 
>> first before I can create sub-collections.
>>
>> It also doesn't correspond to what we expect from most file systems.
>>
>> Just interested in knowing before I implement the not insignificant 
>> amount of code to enforce this.
>>
>>
>> -- 
>>
>> Mike Douglass                           [email-masked]
>> Senior Systems Programmer
>> Communication & Collaboration Technologies      518 276 6780(voice) 2809
>> (fax)
>> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>>
>> _______________________________________________
>> Ietf-caldav mailing list -- [email-masked]
>> See http://ietf.webdav.org/caldav/ for more CalDAV resources
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Date: Sat, 20 Aug 2005 13:30:17 -0700
To: Mike Douglass <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

The way we'd been thinking about multiple nested calendar collections 
was that there would have to be some rhyme or reason to why an event 
would be in one or the other.

If a user has two separate calendar collections, home and work, we 
defined what that means -- they really intend the events to be 
displayed separately and probably share those two calendars to separate 
sets of people (this solves required use cases)

But if we have /users/lisa/work, /users/lisa/work/part1 and 
/users/lisa/work/part2 then we have a lot of open issues...
    * How does the client know whether to put an event in 
/users/lisa/work, or in part1 or part2?
    * Does it mean something to have part1 and part2?  Are clients 
supposed to display any differently depending on where the event is?
    * Does the server handle the three collections differently? Or do 
they all get included in REPORT? And if they're all in the same REPORTs 
then what's the utility of having them split up?
    * If the 'work' event collection gets split up, how does that affect 
other clients who do synchronization? Can they identify that an event 
was the same as the previous and whether it was changed or not?  
(changes might get lost during a reorg, in other words)
    * Finally, what use cases does it solve?  How difficult is it if an 
event collection grows big?  How big? Can we characterize the cost?

I wouldn't recommend getting users to split their calendar collections 
(although note that I may not understand what use case or problem you 
have in mind when you describe the user moving "everything out first")  
.  Unless the user decides they really have two semantically different 
calendars, all the events for a calendar really do belong together.  At 
OSAF we're working with moderately large 3000-event calendars which is 
not at all unreasonable to handle -- and note that Apple iCal 
performance seems not to suck even putting all those events in one 
file.

Yes, it's work to enforce the limitation we described, but it's also 
work to handle the flexibility.  Work for clients is even worse than 
work for servers.  And there's the cost in specification work, 
specification complexity and interoperability testing of the various 
cases and behaviors.  The tradeoff Bernard and Cyrus and I have settled 
on so far did involve considering performance and the other factors you 
and I have mentioned.

Lisa

On Aug 20, 2005, at 1:15 PM, Mike Douglass wrote:

> I asked about this but can't find any response:
>
> Why this restriction? (4.3):
>
> Calendar collections MUST NOT contain other calendar collections.
>
> It certainly makes things difficult if my event collection grows big 
> and I want to split it up. As a user I have to move everything out 
> first before I can create sub-collections.
>
> It also doesn't correspond to what we expect from most file systems.
>
> Just interested in knowing before I implement the not insignificant 
> amount of code to enforce this.
>
>
> -- 
>
> Mike Douglass                           [email-masked]
> Senior Systems Programmer
> Communication & Collaboration Technologies      518 276 6780(voice) 
> 2809
> (fax)
> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Calendar collections
Date: Sat, 20 Aug 2005 22:27:09 +0200
To: CalDAV DevList <[email-masked]>

On Aug 20, 2005, at 22:15, Mike Douglass wrote:
> Why this restriction? (4.3):
> Calendar collections MUST NOT contain other calendar collections.

You might want to check the archives for that, it was discussed in the 
past:
   http://lists.osafoundation.org/pipermail/ietf-caldav/

Should there be a CalDAV FAQ?

Personally I still have the opinion that nested calendars should be 
possible.

regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Sat, 20 Aug 2005 16:15:00 -0400
From: Mike Douglass <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Calendar collections

I asked about this but can't find any response:

Why this restriction? (4.3):

Calendar collections MUST NOT contain other calendar collections.

It certainly makes things difficult if my event collection grows big and 
I want to split it up. As a user I have to move everything out first 
before I can create sub-collections.

It also doesn't correspond to what we expect from most file systems.

Just interested in knowing before I implement the not insignificant 
amount of code to enforce this.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Tue, 16 Aug 2005 09:59:49 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] calendar-schedule support on servers?

Kervin L. Pierre wrote:

> Is there planned support for calendar-schedule,
> http://ietfreport.isoc.org/idref/draft-desruisseaux-caldav-sched/
> in any of the servers being developed?

definitely in cosmo, at some point down the road.

Date: Tue, 16 Aug 2005 10:38:41 -0400
From: Cyrus Daboo <[email-masked]>
To: "Kervin L. Pierre" <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] calendar-schedule support on servers?

Hi Kervin,

--On August 16, 2005 10:16:51 AM -0400 "Kervin L. Pierre" 
<[email-masked]> wrote:

> Is there planned support for calendar-schedule,
> http://ietfreport.isoc.org/idref/draft-desruisseaux-caldav-sched/
> in any of the servers being developed?
>
> Oracle? Cosmo? others?
>
> calendar-schedule's functionality seems
> useful, but will it be widely implemented?

That draft is still in the early stages and there will likely be some 
significant revisions over the coming months as the protocol is firmed up. 
I certainly have plans to add scheduling functionality to our Apache 
Slide-based CalDAV server and our client product suite, once we get close 
to a stable spec. I suspect many other will do the same as the scheduling 
portion of CalDAV is as important as the basic access capability IMHO.

-- 
Cyrus Daboo

Date: Tue, 16 Aug 2005 10:16:51 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] calendar-schedule support on servers?

Hello,

Is there planned support for calendar-schedule,
http://ietfreport.isoc.org/idref/draft-desruisseaux-caldav-sched/
in any of the servers being developed?

Oracle? Cosmo? others?

calendar-schedule's functionality seems
useful, but will it be widely implemented?

Regards,
Kervin

Date: Fri, 12 Aug 2005 16:58:52 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] calendar-description property and language

Lisa Dusseault wrote:
> How about this conformance language:
> 
>               This property MAY be protected and SHOULD NOT be returned
>               by a PROPFIND allprop request (as defined in Section 12.14.1
>               of <xref target="RFC2518"/>). Servers MUST preserve the human
>               language of the description using the xml:lang attribute if
>               language information is provided by the client, and MUST
>               provide that information in subsequent PROPFIND responses.

i have no problem with that.

Date: Fri, 12 Aug 2005 16:53:30 -0700
To: "Bernard Desruisseaux" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Subject: Re: [Ietf-caldav] calendar-description property and language
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Cc: [email-masked]

How about this conformance language:

               This property MAY be protected and SHOULD NOT be returned
               by a PROPFIND allprop request (as defined in Section 12.14.1
               of <xref target="RFC2518"/>). Servers MUST preserve the human
               language of the description using the xml:lang attribute if
               language information is provided by the client, and MUST
               provide that information in subsequent PROPFIND responses.

Lisa

On Thu, 11 Aug 2005 12:43:59 -0700, Bernard Desruisseaux  
<[email-masked]> wrote:

> Actually this text was copied and pasted from section 5.3.
> DAV:supported-privilege-set of RFC 3744 [WebDAV ACL].
>
> We wanted the definition of CALDAV:calendar-description
> to be in line with the definition of DAV:description.
>
> xml:lang is discussed in RFC2518, RFC3253, and RFC3744...
> but not enough I guess.
>
> I don't believe you can PROPATCH multiple values of a given
> property with different xml:lang values. Nor retrieve multiple
> values of a given property with different xml:lang values with
> PROPFIND.
>
> My understanding is that if your server knows of multiple
> values for different languages for a given property (by
> some proprietary way) it should consider the value of the
> Accept-Language request header to decide which value to
> return.
>
> Cheers,
> Bernard
>
> Cyrus Daboo wrote:
>> Hi Brian,
>>  --On August 10, 2005 7:09:39 PM -0700 Brian Moseley  
>> <[email-masked]> wrote:
>>
>>> in defining the calendar-description property, section 4.4.1 mentions
>>> that "servers MUST indicate the human language of the description using
>>> the xml:lang attribute and SHOULD consider the HTTP Accept-Language
>>> request header when selecting one of multiple available languages".
>>>
>>> what exactly does it mean for a server to "select one of multiple
>>> available languages"? does this imply that the server could store
>>> multiple values for the property, each corresponding to a different
>>> language? i'm not seeing anything in rfc 2518 that supports either
>>> setting or returning multiple values for a property, nor do i see
>>> anything in the caldav draft that defines sub-elements for the
>>> calendar-description element.
>>   In an ideal world it would be nice to have multilingual webdav  
>> properties: i.e. the ability to set different values for different  
>> languages for the same property, and have the server automatically  
>> return the appropriate language variant of the property value based on  
>> the Accept-Language header provided by the client.
>>  In the real world I don't know any servers that can do that, so  
>> perhaps we are being to optimistic with that sentence in the CalDAV  
>> spec.
>>
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Fri, 12 Aug 2005 10:17:09 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] calendar-description property and language

Bernard Desruisseaux wrote:

> My understanding is that if your server knows of multiple
> values for different languages for a given property (by
> some proprietary way) it should consider the value of the
> Accept-Language request header to decide which value to
> return.

thanks for the explanation. i wonder if there are any real-world 
examples of this behavior. it seems to me like an attempt to be overly 
accomodating.

Content-Class: urn:content-classes:message
Subject: RE: [Ietf-caldav] calendar-description property and language
Date: Fri, 12 Aug 2005 00:26:15 -0700
From: Cameron Stillion <[email-masked]>
To: "Bernard Desruisseaux" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: [email-masked]

Localization of compile-time strings is perfectly reasonable, and
localizing a server or client is common for vendors who target
international markets.

But localization of content? Unless it's a bad babelfish-like automated
translation, I cannot imagine users wanting to submit multiple values
(one for each language), and if they did, which one would a client
application display? OS-selected UI language? Application-specific UI
language? Keyboard input language? Server-installed language? All could
be different, in fact. =20

It's too frightening to pursue...

I imagine that separate calendars should be stored and/or generated.
And isn't XML/XSL the grand unified theory of serving up special content
based on endpoint capabilities?

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Desruisseaux
Sent: Thursday.11.August.2005 12.44
To: Cyrus Daboo
Cc: [email-masked]
Subject: Re: [Ietf-caldav] calendar-description property and language

Actually this text was copied and pasted from section 5.3.
DAV:supported-privilege-set of RFC 3744 [WebDAV ACL].

We wanted the definition of CALDAV:calendar-description to be in line
with the definition of DAV:description.

xml:lang is discussed in RFC2518, RFC3253, and RFC3744...
but not enough I guess.

I don't believe you can PROPATCH multiple values of a given property
with different xml:lang values. Nor retrieve multiple values of a given
property with different xml:lang values with PROPFIND.

My understanding is that if your server knows of multiple values for
different languages for a given property (by some proprietary way) it
should consider the value of the Accept-Language request header to
decide which value to return.

Cheers,
Bernard

Cyrus Daboo wrote:
> Hi Brian,
>=20
> --On August 10, 2005 7:09:39 PM -0700 Brian Moseley=20
> <[email-masked]> wrote:
>=20
>> in defining the calendar-description property, section 4.4.1 mentions

>> that "servers MUST indicate the human language of the description=20
>> using the xml:lang attribute and SHOULD consider the HTTP=20
>> Accept-Language request header when selecting one of multiple
available languages".
>>
>> what exactly does it mean for a server to "select one of multiple=20
>> available languages"? does this imply that the server could store=20
>> multiple values for the property, each corresponding to a different=20
>> language? i'm not seeing anything in rfc 2518 that supports either=20
>> setting or returning multiple values for a property, nor do i see=20
>> anything in the caldav draft that defines sub-elements for the=20
>> calendar-description element.
>=20
>=20
> In an ideal world it would be nice to have multilingual webdav
> properties: i.e. the ability to set different values for different=20
> languages for the same property, and have the server automatically=20
> return the appropriate language variant of the property value based on

> the Accept-Language header provided by the client.
>=20
> In the real world I don't know any servers that can do that, so=20
> perhaps we are being to optimistic with that sentence in the CalDAV
spec.
>=20

_______________________________________________
Ietf-caldav mailing list -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 11 Aug 2005 15:43:59 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] calendar-description property and language
Cc: [email-masked]

Actually this text was copied and pasted from section 5.3.
DAV:supported-privilege-set of RFC 3744 [WebDAV ACL].

We wanted the definition of CALDAV:calendar-description
to be in line with the definition of DAV:description.

xml:lang is discussed in RFC2518, RFC3253, and RFC3744...
but not enough I guess.

I don't believe you can PROPATCH multiple values of a given
property with different xml:lang values. Nor retrieve multiple
values of a given property with different xml:lang values with
PROPFIND.

My understanding is that if your server knows of multiple
values for different languages for a given property (by
some proprietary way) it should consider the value of the
Accept-Language request header to decide which value to
return.

Cheers,
Bernard

Cyrus Daboo wrote:
> Hi Brian,
> 
> --On August 10, 2005 7:09:39 PM -0700 Brian Moseley 
> <[email-masked]> wrote:
> 
>> in defining the calendar-description property, section 4.4.1 mentions
>> that "servers MUST indicate the human language of the description using
>> the xml:lang attribute and SHOULD consider the HTTP Accept-Language
>> request header when selecting one of multiple available languages".
>>
>> what exactly does it mean for a server to "select one of multiple
>> available languages"? does this imply that the server could store
>> multiple values for the property, each corresponding to a different
>> language? i'm not seeing anything in rfc 2518 that supports either
>> setting or returning multiple values for a property, nor do i see
>> anything in the caldav draft that defines sub-elements for the
>> calendar-description element.
> 
> 
> In an ideal world it would be nice to have multilingual webdav 
> properties: i.e. the ability to set different values for different 
> languages for the same property, and have the server automatically 
> return the appropriate language variant of the property value based on 
> the Accept-Language header provided by the client.
> 
> In the real world I don't know any servers that can do that, so perhaps 
> we are being to optimistic with that sentence in the CalDAV spec.
> 

Date: Thu, 11 Aug 2005 10:39:50 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] calendar-description property and language

Cyrus Daboo wrote:

> In an ideal world it would be nice to have multilingual webdav 
> properties: i.e. the ability to set different values for different 
> languages for the same property, and have the server automatically 
> return the appropriate language variant of the property value based on 
> the Accept-Language header provided by the client.

agree.

> In the real world I don't know any servers that can do that, so perhaps 
> we are being to optimistic with that sentence in the CalDAV spec.

ok. i'll ignore the xml:lang attribute for now and wait to see what 
changes in the next draft. thanks.

Date: Thu, 11 Aug 2005 10:04:08 -0400
From: Cyrus Daboo <[email-masked]>
To: Brian Moseley <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] calendar-description property and language

Hi Brian,

--On August 10, 2005 7:09:39 PM -0700 Brian Moseley <[email-masked]> 
wrote:

> in defining the calendar-description property, section 4.4.1 mentions
> that "servers MUST indicate the human language of the description using
> the xml:lang attribute and SHOULD consider the HTTP Accept-Language
> request header when selecting one of multiple available languages".
>
> what exactly does it mean for a server to "select one of multiple
> available languages"? does this imply that the server could store
> multiple values for the property, each corresponding to a different
> language? i'm not seeing anything in rfc 2518 that supports either
> setting or returning multiple values for a property, nor do i see
> anything in the caldav draft that defines sub-elements for the
> calendar-description element.

In an ideal world it would be nice to have multilingual webdav properties: 
i.e. the ability to set different values for different languages for the 
same property, and have the server automatically return the appropriate 
language variant of the property value based on the Accept-Language header 
provided by the client.

In the real world I don't know any servers that can do that, so perhaps we 
are being to optimistic with that sentence in the CalDAV spec.

-- 
Cyrus Daboo

Date: Wed, 10 Aug 2005 19:09:39 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] calendar-description property and language

in defining the calendar-description property, section 4.4.1 mentions 
that "servers MUST indicate the human language of the description using 
the xml:lang attribute and SHOULD consider the HTTP Accept-Language 
request header when selecting one of multiple available languages".

what exactly does it mean for a server to "select one of multiple 
available languages"? does this imply that the server could store 
multiple values for the property, each corresponding to a different 
language? i'm not seeing anything in rfc 2518 that supports either 
setting or returning multiple values for a property, nor do i see 
anything in the caldav draft that defines sub-elements for the 
calendar-description element.

Date: Tue, 09 Aug 2005 22:29:26 -0400
To: [email-masked], [email-masked]
From: Tim Hare <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-caldav] Re: xCal - namespace URL

<html>
<body>
Actually, if I recall my XML rules, you can code:<br><br>
<br>
<pre>&lt;xCal:iCalendar
xmlns:xCal=&quot;http://ietf.org/rfc/rfcXXXX.txt&quot;&gt;

</pre>Namespaces apply to the containing element as well. And I agree
that the iCalendar element should be in a namespace. Just for
human-readability reasons it associates the iCalendar with the xCal
namespace, and that's a good thing to be reminded ot.<br><br>
At 04:52 PM 8/9/2005, Doug Royer wrote:<br><br>
<br>
<blockquote type=cite class=cite cite="">Julian Reschke wrote:<br>
<blockquote type=cite class=cite cite=""><br>
Just two quick formal comments...:<br>
1) Is it intentional that in the examples, the iCalendar container
element is in no namespace?</blockquote><br>
I think we need to have it in a namespace.<br>
I can go ether way.<br><br>
I think we need to define one so that mixed content can<br>
exist in an XML file.<br><br>
<blockquote type=cite class=cite cite="">2) I don't think the IETF will
let you use something like
&quot;<a href="http://ietf.org/rfc/rfcXXXX.txt" eudora="autourl">
http://ietf.org/rfc/rfcXXXX.txt</a>&quot; as namespace name; but if they
do, you probably should use
&quot;<a href="http://ietf.org/rfc/rfcXXXX" eudora="autourl">
http://ietf.org/rfc/rfcXXXX</a>&quot; (no extension)
instead.</blockquote><br>
:-)<br><br>
-- <br><br>
Doug
Royer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<a href="http://inet-consulting.com/" eudora="autourl">
http://INET-Consulting.com</a><br>
-------------------------------|-----------------------------<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
We Do Standards - You Need Standards<br><br>
<br><br>
<br>
</blockquote>
<x-sigsep><p></x-sigsep>
Tim Hare<br>
Interested Bystander, Non-Inc.</body>
</html>

Content-class: urn:content-classes:message
Subject: RE: [Ietf-caldav] Re: xCal - resubmitted - file name suffix
Date: Tue, 9 Aug 2005 17:59:37 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked]

The multiple dots have no ill effects to users of Windows versions that
support long filenames (XP, 2000, and perhaps 98, though to a limited
degree) - only the final dot extension is meaningful when associating
application behaviors or displaying icons, etc. The rest of the string
is considered the filename sans extension. Like the .tar example, this
leaves further "unwrapping" of the file up to the application.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, August 09, 2005 1:47 PM
To: [email-masked]
Cc: Calsify; CalDAV DevList; [email-masked]
Subject: [Ietf-caldav] Re: xCal - resubmitted - file name suffix

[ I have set the REPLY-TO to the [email-masked] mailing
   list - This is of interest to CALSIFY and CALDAV users, but not
   really 'on topic' - Join at
   http://inet-consulting.com/mailman/listinfo/xcal ]

As to the file name suffix point . Many insisted (Mostly Microsoft and
Microsoft application developers) that iCal define a file extension.

And as I have noticed that MANY implementations store ICS files without
their text/calendar MIME header. I suspect many will for xCAL. So
without a MIME type in the file, many data typing engines would fail if
it were not for a file name suffix.

So xCal has a file extension. I do not care what it is.
And I do not care how many 'dots' are in the file name as long as the
OS's and their applications allow for it.

Cameron Stillion wrote:

> REBTW2: Extension "stacking" is not "unsupported" by most systems=20
> either. It works fine in Unix, Mac, and Windows.

It is supported by some POSIX (UNIX, Linux, BSD, and newer
Mac) applications, but not those OS's.

In fact on those POSIX OS's the 'dot' means nothing at all and it is
simply another character in the file name that can have zero to many
'dot's in the file name.

Cameron - Question: Can the windows registry handle multiple DOTs in
suffixes to files on what ever are the top most Windows versions in use?

My VERY LIMITED knowledge and testing says no, but I might not know what
I am doing as I use POSIX systems for almost everything.

--=20

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

Date: Tue, 09 Aug 2005 17:19:36 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] draft-royer-timezone-registry-03.txt
Reply-To: [email-masked]

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

[ REPLY-TO set to the time zone mailing list - see end of this message ]

I have started the change of removing the SERVER part
from the IANA registry.

In this draft, the TZID will list the official IANA
registry name for the time zone. And the TZURL will point to
the server that supplies the details.

Discussion takes place on [email-masked]

Copies of the draft at:

   http://INET-Consulting.com/draft-royer-timezone-registry-03.html
   http://INET-Consulting.com/draft-royer-timezone-registry-03.txt
   http://INET-Consulting.com/draft-royer-timezone-registry-03.xml

JOIN the TimeZone mailing list at:

     http://inet-consulting.com/mailman/listinfo/timezone

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------090908080802080608050808
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090908080802080608050808--

Date: Tue, 09 Aug 2005 14:52:43 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-caldav] xCal - namespace URL
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040408070303080807090907
Content-Type: multipart/mixed; boundary="------------030304040503050005060403"

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

Julian Reschke wrote:
> 
> 
> Just two quick formal comments...:
> 
> 1) Is it intentional that in the examples, the iCalendar container 
> element is in no namespace?

I think we need to have it in a namespace.
I can go ether way.

I think we need to define one so that mixed content can
exist in an XML file.

> 2) I don't think the IETF will let you use something like 
> "http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they do, you 
> probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

:-)

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------030304040503050005060403
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030304040503050005060403--

--------------ms040408070303080807090907
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040408070303080807090907--

Date: Tue, 09 Aug 2005 14:47:10 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-caldav] Re: xCal - resubmitted - file name suffix
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010705010402090100040405
Content-Type: multipart/mixed; boundary="------------080208010200080206020103"

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

[ I have set the REPLY-TO to the [email-masked] mailing
   list - This is of interest to CALSIFY and CALDAV users, but not
   really 'on topic' - Join at
   http://inet-consulting.com/mailman/listinfo/xcal ]

As to the file name suffix point . Many insisted (Mostly Microsoft and
Microsoft application developers) that iCal define a file extension.

And as I have noticed that MANY implementations store ICS files without
their text/calendar MIME header. I suspect many will for xCAL. So
without a MIME type in the file, many data typing engines would fail
if it were not for a file name suffix.

So xCal has a file extension. I do not care what it is.
And I do not care how many 'dots' are in the file name as
long as the OS's and their applications allow for it.

Cameron Stillion wrote:

> REBTW2: Extension "stacking" is not "unsupported" by most systems
> either. It works fine in Unix, Mac, and Windows. 

It is supported by some POSIX (UNIX, Linux, BSD, and newer
Mac) applications, but not those OS's.

In fact on those POSIX OS's the 'dot' means nothing at all
and it is simply another character in the file name that can
have zero to many 'dot's in the file name.

Cameron - Question: Can the windows registry handle multiple DOTs
in suffixes to files on what ever are the top most Windows
versions in use?

My VERY LIMITED knowledge and testing says no, but I might not
know what I am doing as I use POSIX systems for almost everything.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------080208010200080206020103
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------080208010200080206020103--

--------------ms010705010402090100040405
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010705010402090100040405--

Date: Tue, 09 Aug 2005 14:18:30 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] RE: [Ietf-caldav] xCal - resubmitted.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000505060505050205020801
Content-Type: multipart/mixed; boundary="------------030001070904020705060900"

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

[ I have set the REPLY-TO the [email-masked] mailing
   list - This is of interest to CALSIFY and CALDAV users, but not
   really 'on topic' - Join at
   http://inet-consulting.com/mailman/listinfo/xcal ]

> Anyway, is there anyone else who feels as I do that enforcing both xcal
> and ical as multipart alternative is overkill?  Or is this also beyond
> the scope of this proposal?

This is left over from the CALSCH days.

When Frank, Surendra, and I did the first XCAL, we were told
by the AD's at the time that they would not endorse ANOTHER
calendar data format, unless it was an alternate view of
iCalendar data. So the agreed solution was that xCal objects
would be attached as an alternate view to iCal objects.

Currently iMIP requires that people use S/MIME. I do not recall
seeing many S/MIME iCalendar emails.

The danger here is that we re-invent the wheel breaking things.
The purpose of CALSIFY is to simplify and make a set of objects
and procedures that will enable iCal and vendors to have standard
calendaring objects. If we open up the debate to XML 'IS calendaring'
then all that is compatibility that we already have is lost.

There are many XML parsers out there and XML can be
transformed back into iCal (see my posting of the XSLT
translation on the xCal mailing list).

How do we enable XML and not disrupt iCal ?

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------030001070904020705060900
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030001070904020705060900--

--------------ms000505060505050205020801
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000505060505050205020801--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-caldav] xCal - resubmitted.
Date: Tue, 9 Aug 2005 11:16:10 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Helge Hess" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>

I appreciate your point Helge - still, the standard can scarcely avoid
using a filename (see attachments section) and actually, this seems like
a very simple and meaningful place to provide interoperability
guidelines. Most other "file format" standards cannot avoid it, or
choose instead to specify it. That's probably why it's here in the first
place.

Are you suggesting we remove all references to filenames/extensions from
this draft? And in general, would you say we should not suggest anything
outside the internals of the MIME type itself? =20
In practice, I find this incomplete - but if you think it belongs
elsewhere, that's fine.

REBTW1: the distinction between an encapsulated format and a
specialization of a format is a fine one.  I rather think extensions are
useful hints, not strictly delineations of encapsulation or (indeed) of
specialization.  But the similarities here are useful. I understand your
concern, but the purpose is merely informational, not a strict
non-repudiation of format, encoding, or schema.

REBTW2: Extension "stacking" is not "unsupported" by most systems
either. It works fine in Unix, Mac, and Windows.=20

Anyway, is there anyone else who feels as I do that enforcing both xcal
and ical as multipart alternative is overkill?  Or is this also beyond
the scope of this proposal?

-----Original Message-----
From: Helge Hess [mailto:[email-masked]]=20
Sent: Tuesday, August 09, 2005 9:54 AM
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

now thats getting entirely off-topic, but anwyay ...

On 9. Aug 2005, at 18:12 Uhr, Cameron Stillion wrote:
> (interestingly enough, it seems MacOS is now, in many cases, favoring=20
> file extensions and "all the data in the 'data fork'" rather than=20
> using separate resource forks.  Fascinating...)

Its that way for a long time (~4 years?), since NeXTstep 5 aka MacOSX.

If you are interested on the topic:
   http://arstechnica.com/reviews/os/macosx-10.4.ars/11

> But philosophically, why not put "publisher's clearinghouse=20
> sweepstakes" on the OUTSIDE of the envelope as well?

You can, but you started to discuss clever ways of file extension
mapping which is not used that way anywhere (except for informational
purposes). This is IMHO out of scope of the RFC, better avoid the whole
issue.

BTW: the example of "file.xml.xcal" is _not_ the same thing like
"file.tar.gz". The latter forms no typing hierarchy but a stacking of
formats (converting a .gz will result in a .tar, its not a special type
or "subclass" of .tar). BTW2: Few systems support such stacking which is
why .tgz is not so unusual either.

> If we speak of attachments, we're going to have to pick something to=20
> use in our examples.

I don't see how this would matter for the xCal spec. It describes the
data format, not the transport and therefore doesn't include any
filenames (with or without extensions).
Do I miss something?

Greets,
   Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] xCal - resubmitted.
Date: Tue, 9 Aug 2005 18:54:27 +0200
To: "Cameron Stillion" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>

now thats getting entirely off-topic, but anwyay ...

On 9. Aug 2005, at 18:12 Uhr, Cameron Stillion wrote:
> (interestingly enough, it seems MacOS is now, in many cases, favoring
> file extensions and "all the data in the 'data fork'" rather than  
> using
> separate resource forks.  Fascinating...)

Its that way for a long time (~4 years?), since NeXTstep 5 aka MacOSX.

If you are interested on the topic:
   http://arstechnica.com/reviews/os/macosx-10.4.ars/11

> But philosophically, why not put "publisher's
> clearinghouse sweepstakes" on the OUTSIDE of the envelope as well?

You can, but you started to discuss clever ways of file extension  
mapping which is not used that way anywhere (except for informational  
purposes). This is IMHO out of scope of the RFC, better avoid the  
whole issue.

BTW: the example of "file.xml.xcal" is _not_ the same thing like  
"file.tar.gz". The latter forms no typing hierarchy but a stacking of  
formats (converting a .gz will result in a .tar, its not a special  
type or "subclass" of .tar). BTW2: Few systems support such stacking  
which is why .tgz is not so unusual either.

> If we speak of attachments, we're going to have to pick something  
> to use in our
> examples.

I don't see how this would matter for the xCal spec. It describes the  
data format, not the transport and therefore doesn't include any  
filenames (with or without extensions).
Do I miss something?

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Content-class: urn:content-classes:message
Subject: RE: [Ietf-caldav] xCal - resubmitted.
Date: Tue, 9 Aug 2005 09:12:14 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Helge Hess" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>

Not instead of - just in addition to. It's just a hint.  Windows also
has "forested" files, and "structured" files, just like Mac's "resource
forks". I agree you'd never want to use a filename INSTEAD of the actual
annotations internally.  But philosophically, why not put "publisher's
clearinghouse sweepstakes" on the OUTSIDE of the envelope as well?=20

Perhaps it doesn't belong in this particular document, though it seems
many format documents have trouble avoiding it.  If we speak of
attachments, we're going to have to pick something to use in our
examples.

Design sneaks into implementation...

(interestingly enough, it seems MacOS is now, in many cases, favoring
file extensions and "all the data in the 'data fork'" rather than using
separate resource forks.  Fascinating...)

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Helge Hess
Sent: Tuesday.09.August.2005 04.20
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

On Aug 9, 2005, at 12:59, Cameron Stillion wrote:
> The idea here is to give processing software an idea what is inside=20
> the envelope.  If you are familiar with the envelope/letter approach=20
> to data abstraction, it is a very powerful metaphor.  This proposal=20
> mentions that it will NOT use .xml as an extensions - presumably for=20
> this same reason.  If all applications, MTAs, and processing software=20
> of all operating systems begin to name data files based on the use of=20
> xml, pretty soon all documents will have the .xml extension. Great. =20
> We might as well call everything data.xml, and go ahead with a full=20
> parse of the content to determine what to do next.  The performance=20
> implications of this are rather dismal, and the design I find not very

> useful.  Why NOT give a hint as to the content using an extension?

While I agree with all of that, I honestly think that it doesn't belong
into a specification on the xCal data format.

Standardizing content typing is a completely different story and
actually one which is already covered and widely implemented in RFCs:=20
MIME. This is used for both, transmitting iCal/xCal by mail and for
storing iCal/xCal content in HTTP servers.
How MIME is mapped to local storages (extensions, resource forks, FS
annotations, spotlight attributes etc) is entirely operating system
dependend.

So in my opinion you might want to document a file-extension "best
practice" for xCal, but it doesn't really belong into the RFC. The RFC
should just outline the MIME type.

> I do not know how a more simple and direct way of giving a hint to the

> processing software might be, than to annotate the name of the content
> -
> but I am always willing to learn.  What are these "better ways" you=20
> speak of?

Well, annotating the content instead of the name? Googling for MacOS
resource forks might be a starting point to find out why file extensions
are problematic ;-)

Greets,
   Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

_______________________________________________
Ietf-caldav mailing list -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Tue, 09 Aug 2005 16:29:07 +0200
From: Julian Reschke <[email-masked]>
To: Dan Connolly <[email-masked]>
Subject: Re: [Ietf-caldav] xCal - resubmitted.
Cc: [email-masked], Calsify <[email-masked]>, "[email-masked]" <[email-masked]>, Doug Royer <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked]

Dan Connolly wrote:
> On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
> [...]
> 
>>>Copies of the draft at:
>>>
>>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
>>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
>>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
>>
>>Just two quick formal comments...:
>>
>>1) Is it intentional that in the examples, the iCalendar container 
>>element is in no namespace?
>>
>>2) I don't think the IETF will let you use something like 
>>"http://ietf.org/rfc/rfcXXXX.txt" as namespace name;
> 
> 
> Right; I gather Best Current Practice is...
> 
> [[[
> If the registrant wishes to
>    have a URI assigned, then a URN of the form
> 
>       urn:ietf:params:xml:<class>:<id>
> 
>    will be assigned where <class> is the type of the document being
>    registered (see below).
> ]]]
>  -- http://www.faqs.org/rfcs/rfc3688.html

One could probably also use: <urn:ietf:rfc:NNNN> (see 
<http://ietf.org/rfc/rfc2648>).

> ...

Best regards, Julian

Subject: Re: [Ietf-caldav] xCal - resubmitted.
From: Dan Connolly <[email-masked]>
To: Julian Reschke <[email-masked]>
Organization: World Wide Web Consortium (http://www.w3.org/)
Date: Tue, 09 Aug 2005 09:25:18 -0500
Cc: [email-masked], Calsify <[email-masked]>, "[email-masked]" <[email-masked]>, Doug Royer <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked]

On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
[...]
> > Copies of the draft at:
> > 
> >     http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
> >     http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
> >     http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
> Just two quick formal comments...:
> 
> 1) Is it intentional that in the examples, the iCalendar container 
> element is in no namespace?
> 
> 2) I don't think the IETF will let you use something like 
> "http://ietf.org/rfc/rfcXXXX.txt" as namespace name;

Right; I gather Best Current Practice is...

[[[
If the registrant wishes to
   have a URI assigned, then a URN of the form

      urn:ietf:params:xml:<class>:<id>

   will be assigned where <class> is the type of the document being
   registered (see below).
]]]
 -- http://www.faqs.org/rfcs/rfc3688.html

Meanwhile, you can get an http namespace name from W3C if you like:

"W3C provides the service of allocating and maintaining persistent URIs
so that those URIs remain stable during discussions. Allocation does not
imply any endorsement by W3C of the related specifications."
 -- http://www.w3.org/1999/10/nsuri

see for example http://www.w3.org/2005/Atom

>  but if they do, you 
> probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

Actually I think the .txt form is more official:

[[
The full
   text of the specification is then available using the following URL:

      http://www.ietf.org/rfc/rfcNNNN.txt

   where "NNNN" is the number of the RFC being submitted.
]]
 -- section 3.4.2 Submitting IETF Documents to JTC1
http://www.ietf.org/rfc/rfc3563.txt

The /rfc/rfcXXXX form is supported by accident, as far as I can tell.

> Best regards, Julian

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] xCal - resubmitted.
Date: Tue, 9 Aug 2005 13:20:22 +0200
To: "Cameron Stillion" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>

On Aug 9, 2005, at 12:59, Cameron Stillion wrote:
> The idea here is to give processing software an idea what is inside the
> envelope.  If you are familiar with the envelope/letter approach to 
> data
> abstraction, it is a very powerful metaphor.  This proposal mentions
> that it will NOT use .xml as an extensions - presumably for this same
> reason.  If all applications, MTAs, and processing software of all
> operating systems begin to name data files based on the use of xml,
> pretty soon all documents will have the .xml extension. Great.  We 
> might
> as well call everything data.xml, and go ahead with a full parse of the
> content to determine what to do next.  The performance implications of
> this are rather dismal, and the design I find not very useful.  Why NOT
> give a hint as to the content using an extension?

While I agree with all of that, I honestly think that it doesn't belong 
into a specification on the xCal data format.

Standardizing content typing is a completely different story and 
actually one which is already covered and widely implemented in RFCs: 
MIME. This is used for both, transmitting iCal/xCal by mail and for 
storing iCal/xCal content in HTTP servers.
How MIME is mapped to local storages (extensions, resource forks, FS 
annotations, spotlight attributes etc) is entirely operating system 
dependend.

So in my opinion you might want to document a file-extension "best 
practice" for xCal, but it doesn't really belong into the RFC. The RFC 
should just outline the MIME type.

> I do not know how a more simple and direct way of giving a hint to the
> processing software might be, than to annotate the name of the content 
> -
> but I am always willing to learn.  What are these "better ways" you
> speak of?

Well, annotating the content instead of the name? Googling for MacOS 
resource forks might be a starting point to find out why file 
extensions are problematic ;-)

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Content-class: urn:content-classes:message
Subject: RE: [Ietf-caldav] xCal - resubmitted.
Date: Tue, 9 Aug 2005 03:59:08 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Reinhold Kainhofer" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>

I'm glad there are others who remember such tools.

Surely there are more stringent mechanisms than looking at the file
extension - this is simply the first hint.  This is the reason that file
extensions were invented, to give the first hint as to what to do with
the file.  It treats the file as an object, and lends the file system an
object-oriented nature.  Applications, verbs, or actions can be
associated with extensions or schemes, or both. =20

Granted, it is not the last word.  I can rename a text file with .exe or
.tar, but in unix or windows or osx, this does not mean it will
execute... And this approach is not specific to any particular OS, to be
sure.

The idea here is to give processing software an idea what is inside the
envelope.  If you are familiar with the envelope/letter approach to data
abstraction, it is a very powerful metaphor.  This proposal mentions
that it will NOT use .xml as an extensions - presumably for this same
reason.  If all applications, MTAs, and processing software of all
operating systems begin to name data files based on the use of xml,
pretty soon all documents will have the .xml extension. Great.  We might
as well call everything data.xml, and go ahead with a full parse of the
content to determine what to do next.  The performance implications of
this are rather dismal, and the design I find not very useful.  Why NOT
give a hint as to the content using an extension?=20

I do not know how a more simple and direct way of giving a hint to the
processing software might be, than to annotate the name of the content -
but I am always willing to learn.  What are these "better ways" you
speak of?=20

Cameron

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]]=20
Sent: Tuesday.09.August.2005 03.23
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

On Tuesday 09 August 2005 11:35, Cameron Stillion wrote:
> 2.12
> 	how about using a double extension - <filename>.xml.xcs
> 	This is reminiscent of tar files for those who are ancient
enough to=20
> remember those

Sorry, but just because tar archives are not common under Windows,
doesn't mean they are ancient. In fact, they are the most common
compressed archive format in Linux and also on Unix systems, far more
popular than zip files!=20
E.g. almost all source code for Linux applications (if not accessed
through svn, cvs or some other versioning system) is distributed as
gzipped tar files or bziped tar files.=20

> - anytime to add another layer of
> schematization over a file, you add an extension.  Why don't we follow

> the same pattern? I can't think of a good reason not to.

File names (and thus also the part after a period in the file name) in
Linux don't really have such a strong binding to the file type than the
file name extensions in Windows.=20

> 	While you're at it - why not go another step further and specify
file=20
> extensions for the different types of iCals (which the ical standard=20
> unfortunately failed to do) - for instance, a meeting request=20
> "method=3D'request'" might have an extension of .xrc while a published =

> calendar "method=3D'publish'" might have an extension of .xcs - this=20
> gives everyone a much more tangible understanding of the data without=20
> having to crack it and parse it first. There's a thought.

As I said, in Linux and unix systems, the file name extension is
typically not associated with the file content as strong as Windows uses
them. Sure, they can be used to indicate the type of a file, but that's
noting more than an indication and doesn't mean it really has to be that
type of file. There are better means of determining the contents of a
file in Linux.

Cheers,
Reinhold
--
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien,
http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: "Cameron Stillion" <[email-masked]>
Subject: Re: [Ietf-caldav] xCal - resubmitted.
Date: Tue, 9 Aug 2005 12:22:31 +0200
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>

--nextPart3176406.cJ48L3No6I
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 09 August 2005 11:35, Cameron Stillion wrote:
> 2.12
> 	how about using a double extension - <filename>.xml.xcs
> 	This is reminiscent of tar files for those who are ancient
> enough to remember those=20

Sorry, but just because tar archives are not common under Windows, doesn't=
=20
mean they are ancient. In fact, they are the most common compressed archive=
=20
format in Linux and also on Unix systems, far more popular than zip files!=
=20
E.g. almost all source code for Linux applications (if not accessed through=
=20
svn, cvs or some other versioning system) is distributed as gzipped tar fil=
es=20
or bziped tar files.=20

> - anytime to add another layer of=20
> schematization over a file, you add an extension.  Why don't we follow
> the same pattern? I can't think of a good reason not to.

=46ile names (and thus also the part after a period in the file name) in Li=
nux=20
don't really have such a strong binding to the file type than the file name=
=20
extensions in Windows.=20

> 	While you're at it - why not go another step further and specify
> file extensions for the different types of iCals (which the ical
> standard unfortunately failed to do) - for instance, a meeting request
> "method=3D'request'" might have an extension of .xrc while a published
> calendar "method=3D'publish'" might have an extension of .xcs - this gives
> everyone a much more tangible understanding of the data without having
> to crack it and parse it first. There's a thought.

As I said, in Linux and unix systems, the file name extension is typically =
not=20
associated with the file content as strong as Windows uses them. Sure, they=
=20
can be used to indicate the type of a file, but that's noting more than an=
=20
indication and doesn't mean it really has to be that type of file. There ar=
e=20
better means of determining the contents of a file in Linux.

Cheers,
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer

--nextPart3176406.cJ48L3No6I
Content-Type: application/pgp-signature

--nextPart3176406.cJ48L3No6I--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-caldav] xCal - resubmitted.
Date: Tue, 9 Aug 2005 02:35:09 -0700
Priority: Non-Urgent
Importance: low
From: "Cameron Stillion" <[email-masked]>
To: "Doug Royer" <[email-masked]>
Cc: [email-masked], Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked], [email-masked]

2.2.1
	Are you minimizing the difference between the inherent unicode
capabilities of XML and the rather esoteric encoding requirements of
iCal? Simply wrapping the data in tags is not really enough...

2.2.2
	isomeric - I think you mean "isometric".  Ah, the difference one
character can make...

	also - why is it required to send an alternate MIME body part in
normal iCal format? Is this format designed to replace the old format?
Ultimately? If so, why should both be required? iCal readers of old can
read xcal via transform, and new applications can easily parse using a
standard xml parser... Why limit all uses of this to also implement the
old way of doing things? This seems counter productive to me.

2.11
	why not simply use "text/xcal" ?=20

	again, why the restriction for backwards compatability? This
sounds like you are enforcing client functionality. How about you allow
the MTA or client application to determine whether or not to send a
downlevel representation?

2.12
	how about using a double extension - <filename>.xml.xcs
	This is reminiscent of tar files for those who are ancient
enough to remember those - anytime to add another layer of
schematization over a file, you add an extension.  Why don't we follow
the same pattern? I can't think of a good reason not to.

	While you're at it - why not go another step further and specify
file extensions for the different types of iCals (which the ical
standard unfortunately failed to do) - for instance, a meeting request
"method=3D'request'" might have an extension of .xrc while a published
calendar "method=3D'publish'" might have an extension of .xcs - this =
gives
everyone a much more tangible understanding of the data without having
to crack it and parse it first. There's a thought.

Date: Tue, 09 Aug 2005 11:08:31 +0200
From: Julian Reschke <[email-masked]>
To: Doug Royer <[email-masked]>
Subject: Re: [Ietf-caldav] xCal - resubmitted.
Cc: [email-masked], Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>

Doug Royer wrote:
> 
> 
> The xCal draft has been rewritten and submitted to the IETF.
> 
> I have an XSLT translation file that I will be releasing
> soon on SourceForge that can translate an xCal object
> back to an iCal object. I am waiting for SourceForge
> to approve the project name.
> 
> Discussion takes place on [email-masked]
> 
> Copies of the draft at:
> 
>     http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
>     http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
>     http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
> 
> 
> JOIN the xCal mailing list at:
> 
>     http://inet-consulting.com/mailman/listinfo/xcal
> 

Just two quick formal comments...:

1) Is it intentional that in the examples, the iCalendar container 
element is in no namespace?

2) I don't think the IETF will let you use something like 
"http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they do, you 
probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

Best regards, Julian

Date: Mon, 08 Aug 2005 14:44:07 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>
Subject: [Ietf-caldav] xCal - resubmitted.

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

The xCal draft has been rewritten and submitted to the IETF.

I have an XSLT translation file that I will be releasing
soon on SourceForge that can translate an xCal object
back to an iCal object. I am waiting for SourceForge
to approve the project name.

Discussion takes place on [email-masked]

Copies of the draft at:

	http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
	http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
	http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml

JOIN the xCal mailing list at:

	http://inet-consulting.com/mailman/listinfo/xcal

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------040500060400060002010604
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------040500060400060002010604--

Date: Mon, 08 Aug 2005 14:57:30 -0400
From: Cyrus Daboo <[email-masked]>
To: "Kervin L. Pierre" <[email-masked]>
Subject: Re: [Ietf-caldav] caldav global addressbook
Cc: CalDAV DevList <[email-masked]>

Hi Kervin,

--On August 8, 2005 2:24:42 PM -0400 "Kervin L. Pierre" 
<[email-masked]> wrote:

>> What type of 'discovery' do you want? Right now there is a way for an
>> individual to find their own 'calendar-home' directory (which would be
>> the 'root' of their personal calendars) and for an individual to find
>> 'calendar-homes' of other users.
>
> My client is a Microsoft Outlook extension,
> [ http://openconnector.org/ ].  I am mapping
> the Outlook/MAPI addressbook interface to
> CalDAV.  Ie. remote, read-only address book.
>
> To do this, the server would have to be able
> to return all principles ( with correct
> permissions of course ), and hopefully run a
> principle search based on a regular expression
> provided by the client.
>
> What I am looking for, I believe, is
> 'calendar-address-set' property
> [ http://ietfreport.isoc.org/idref/draft-dusseault-caldav/#page-22 ]
> with regex functionality.  Does this exist?
>
> Eg....
>       <D:property-search>
>         <D:prop>
>           <C:calendar-address-set/>
>         </D:prop>
>         <D:match>mailto:.*</D:match>
>       </D:property-search>

Assuming that WebDAV principals had an 'email-address' property, then you 
could use the usual WebDAV ACL reports to list and query such principals. 
However, CalDAV does not require any type of email address attribute. That 
is something that you would have to do outside of CalDAV.

-- 
Cyrus Daboo

Date: Mon, 08 Aug 2005 14:24:42 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] caldav global addressbook
Cc: CalDAV DevList <[email-masked]>

Hello Cyrus,

Cyrus Daboo wrote:
> 
> What type of 'discovery' do you want? Right now there is a way for an 
> individual to find their own 'calendar-home' directory (which would be 
> the 'root' of their personal calendars) and for an individual to find 
> 'calendar-homes' of other users.

My client is a Microsoft Outlook extension,
[ http://openconnector.org/ ].  I am mapping
the Outlook/MAPI addressbook interface to
CalDAV.  Ie. remote, read-only address book.

To do this, the server would have to be able
to return all principles ( with correct
permissions of course ), and hopefully run a
principle search based on a regular expression
provided by the client.

What I am looking for, I believe, is
'calendar-address-set' property
[ http://ietfreport.isoc.org/idref/draft-dusseault-caldav/#page-22 ]
with regex functionality.  Does this exist?

Eg....
      <D:property-search>
        <D:prop>
          <C:calendar-address-set/>
        </D:prop>
        <D:match>mailto:.*</D:match>
      </D:property-search>

Or....
       <D:match>mailto:bernard@.*</D:match>

Regards,
Kervin

Date: Mon, 08 Aug 2005 12:19:27 -0400
From: Cyrus Daboo <[email-masked]>
To: "Kervin L. Pierre" <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] caldav global addressbook

Hi Kervin,

--On August 8, 2005 12:14:41 PM -0400 "Kervin L. Pierre" 
<[email-masked]> wrote:

> Apologies if I've missed something obvious or
> a previous discussion, but what are the current
> recommendations, if any, for a global addressbook
> on a CalDAV server?

CalDAV has nothing to say about address books. However, I am working on a 
CalDAV-like proposal for the smart storage/retrieval of vCards in WebDAV. 
That would probably be what you want for handling personal address books 
(as opposed to directories which should be LDAP-based).

> Does/will the CalDAV protocol support any features
> that allows the discovery of other calendars on
> the same CalDAV server?

What type of 'discovery' do you want? Right now there is a way for an 
individual to find their own 'calendar-home' directory (which would be the 
'root' of their personal calendars) and for an individual to find 
'calendar-homes' of other users. There is no way to automatically discover 
other types of hierarchy (e.g. for public calendars, calendars of 
non-principals (rooms, printers etc)). At one point there was a 'namespace' 
option in CalDAV that was similar to the NAMESPACE extension in IMAP, that 
would provide for a broad discovery option, but that was dropped for 
various reasons. It could still be resurrected as an extension at some 
later point if the need arose.

-- 
Cyrus Daboo

Date: Mon, 08 Aug 2005 12:14:41 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] caldav global addressbook

Hello,

Apologies if I've missed something obvious or
a previous discussion, but what are the current
recommendations, if any, for a global addressbook
on a CalDAV server?

Does/will the CalDAV protocol support any features
that allows the discovery of other calendars on
the same CalDAV server?

Regards,
Kervin

Date: Thu, 04 Aug 2005 09:30:03 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Errata on Calconnect Roundtable and Interop Announcement for September 2005
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
1.&nbsp; The registration fee for the Roundtable was mistakenly quoted as
$275 through 15 May 2005.&nbsp; The correct information is $275 through <u>31
August 2005</u>; the registration fee goes up to $325 on <u>1
September 2005</u>.<br>
<br>
2.&nbsp; Apparently there was some garbage HTML hidden before the beginning
of my announcement e-mail which was not visible when I composed it and
does not show in all e-mail clients.&nbsp; However, if it does show in your
client and you wish a revised version of the announcement please let me
know.&nbsp; I hesitate to send the whole thing out again to everybody.<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

Date: Thu, 04 Aug 2005 09:03:47 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Registration open for Calconnect Roundtable and Interop Testing Event,  September 2005 - The Calendaring and Scheduling Consortium
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<!-- Inserted by Calypso -->
<table id="_CalyPrintHeader_" style="display: none; color: black;"
 border="0" cellpadding="0" cellspacing="2" rules="none" width="100%">
  <tbody>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Date:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;12/2/2004 07:52<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;From:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;David C. Thewlis<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;To:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Copy:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"Robert Tolmach - WellGood Group" <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Subject:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso --><!-- Inserted by Calypso -->
<table id="_CalyMsgHeader_" style="display: none; color: rgb(0, 0, 0);"
 bgcolor="#c0c0c0" border="1" cellpadding="2" cellspacing="2"
 rules="none" width="100%">
  <tbody>
    <tr bgcolor="#c0c0c0">
      <td><font color="#000000" face="VERDANA,ARIAL,HELVETICA" size="-2">Received:
from psmtp.com (exprod6mx6.postini.com [64.18.1.146]) by
home.humboldt1.com (8.12.10/8.12.10) with SMTP id iB2Fq3mR014814 for <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004 07:52:03 -0800 (PST)<br>
Received: from source ([208.31.106.91]) by exprod6mx6.postini.com
([64.18.5.10]) with SMTP; Thu, 02 Dec 2004 07:52:02 PST<br>
Received: from aix2.egenconsulting.com (localhost [127.0.0.1]) by
aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP id iB2FlvWi018040
for <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004
10:47:57 -0500<br>
Received: (from majordom@localhost) by aix2.egenconsulting.com
(8.13.1/8.13.1/Submit) id iB2FlvFI018426 for calconnect-l-list; Thu, 2
Dec 2004 10:47:57 -0500<br>
X-Authentication-Warning: aix2.egenconsulting.com: majordom set sender
to <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>
using -f<br>
Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net
[68.230.241.35]) by aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP
id iB2FlcTM019480; Thu, 2 Dec 2004 10:47:38 -0500<br>
Received: from davet23 ([24.254.88.112]) by fed1rmmtao04.cox.net
(InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id
&lt;20041202154833.YTO5357.fed1rmmtao04.cox.net@davet23&gt; Thu, 2 Dec
2004 10:48:33 -0500<br>
Message-ID: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
References: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
X-Mailer: Calypso Version 3.30.00.00 (4)<br>
Date: Thu, 02 Dec 2004 07:48:00 -0800<br>
Reply-To: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
From: "David C. Thewlis" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
To: "calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF
CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
Cc: "Robert Tolmach - WellGood Group" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
Subject: Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
Mime-Version: 1.0<br>
Content-Type: multipart/alternative; boundary="=====_11020024806334=_"<br>
Sender: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
Precedence: bulk<br>
X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624
C:98.9754 )<br>
X-pstn-settings: 5 (2.0000:2.0000) s gt3 gt2 gt1 r p m c <br>
X-pstn-addresses: from <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
forward
(user good) [2395/93] <br>
      </font><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso -->
<div><em>Please note that this announcement is being posted on multiple
calendaring-related reflectors and to the Calconnect mailing lists to
ensure as wide a distribution as possible.&nbsp; Our apologies if you
receive multiple copies.<br>
<br>
</em></div>
<div><em></em><br>
<strong>CALCONNECT ROUNDTABLE IV - 13-15 September 2005</strong> <br>
</div>
<div>&nbsp;</div>
<div><strong>CALCONNECT INTEROP TESTING EVENT -&nbsp;
13-14 September 2005<br>
<br>
</strong></div>
<div>&nbsp;<br>
CalConnect - The Calendaring and Scheduling Consortium - invites you to
our fourth Roundtable and to the associated Calendaring and Scheduling
Interop Testing Event on 13-15 September, 2005 in San Francisco, hosted
by OSAF, the Open Source Applications Foundation.&nbsp; <br>
<br>
<u>Registration is now open for these events as of 4 August 2005.</u><br>
</div>
<br>
<br>
The <b>Roundtable</b>, 13-15 September, will feature Technical
Committee meetings, ad hoc meetings, and a full Plenary of the
Consortium.&nbsp; You must represent a member of CalConnect to attend the
Roundtable <u>unless</u> your organization chooses to participate as
an Observer (a non-member who wishes to attend a Roundtable to evaluate
participation in the Consortium).<br>
<br>
The <b>Interop</b>, 13-14 September (at the same location), will offer
multiple Interop Testing Scenarios including <br>
<ul>
  <li>extensive CalDAV testing, <br>
  </li>
  <li>RFC (iCalendar, iMIP, iTIP) interoperability and RFC conformance
testing</li>
  <li>CALSIFY minimum interoperability testing.&nbsp; <br>
  </li>
</ul>
Participating organizations may choose one or more than one scenario
for testing -- however these scenarios will be going on
simultaneously so you will probably need a person for each scenario you
participate in.&nbsp; <br>
<br>
Interop participation is <u>open to all</u> interested organizations
that wish to test calendaring and scheduling implementations, and <u>is
not limited to members of the Consortium </u>(although members receive
a significant discount on the Interop participation fee). <br>
&nbsp;
<div><strong><br>
REGISTRATION FEES</strong></div>
<div>&nbsp;<br>
<b>Roundtable:</b>&nbsp; $275 per individual until 15
May and $325 thereafter.&nbsp; The Roundtable is limited to representatives
of Consortium members or declared Observers (an non-member that wishes
to attend a Roundtable to evaluate participation in the Consortium). &nbsp; <i>Registration
for the Roundtable does <b>not</b>
include Interop participation.</i><br>
&nbsp;</div>
<div><b>Interop:</b> $1500 for Consortium
members and $2500 for non-members.&nbsp; The registration fee covers two
individuals; additional individuals are $275 each for members or
non-members.&nbsp; (If you are planning to participate in more than one
Interop scenario, or participate in all the TC meetings, you <u>will</u>
need
more than one person and possibly more than two.)&nbsp; <strong></strong><i>The
Interop
Registration Fee <b>also covers participation in the&nbsp;Consortium
Roundtable</b>
for members or declared observers</i>.</div>
<div>&nbsp;<br>
<br>
</div>
<div><b>ADDITIONAL DETAILS AND REGISTRATION INFORMATION</b><br>
<br>
More information on the Roundtable, including logistics, current
schedule and agenda planning, and registration information is available
on the Consortium website at <a
 href="http://www.calconnect.org/roundtable4.html">http://www.calconnect.org/roundtable4.html</a>.&nbsp;
<br>
<br>
More information on the Interop including logistics, planning, and
registration information is available on the Consortium website at <a
 href="http://www.calconnect.org/iopsep2005.html">http://www.calconnect.org/iopsep2005.html</a>.<br>
<br>
You may also go to Consortium site at <a
 href="http://www.calconnect.org">http://www.calconnect.org</a>
and select "Coming Events" from the sidebar to find logistics,
planning and registration information for both the Roundtable and the
Interop.<br>
</div>
<br>
For questions and additional information please contact the
Consortium's Executive Director, Dave Thewlis, via the contact
information listed below. <br>
<div><br>
Space will be limited, so register as soon as possible. <br>
<br>
</div>
<div>Best Regards,</div>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile) &middot; +1 415 946 3454
(fax)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a>
&middot; <a href="mailto:[email-masked]">[email-masked]</a><br>
<br>
</div>
</body>
</html>