[Ietf-caldav] Creating a calendar
TimHare at comcast.net
TimHare at comcast.net
Tue Sep 7 07:38:10 PDT 2004
I think, myself, that this should be a property in a user's directory entry
in some directory accessible via LDAP. I believe one of the iCalendar RFCs
referenced doing this, although a cursory search of RFC 2445 only
references using LDAP in a component property, rather than using LDAP to
locate user calendars. In any case, it is very desirable to be able to use
directory search to find the user's calendar.
At 12:49 PM 8/27/04, Elias Sinderson wrote:
>Lisa Dusseault wrote:
>>I also like the idea of looking at the principal resource to find out
>>more information like where the user's calendar is homed, where the
>>user's other file sharing space can be found, etc. CalDAV would only
>>have to define a property on the principal resource for this to work [...]
>+1 - simple and elegant.
>Cyrus Daboo wrote:
>>Lisa Dusseault wrote:
>>>When a user logs in, the ACL standard defines a REPORT to ask "who am I".
>>>With that report the client gets the mapping from the user's login ID to
>>>a principal URL.
>>But that does not help locating calendars for resources that are not
>>associated with a principal e.g. public calendars, calendars for meeting
>>rooms etc One could argue that you could use DASL to find those things,
>>but I think having a NAMESPACE report would be better.
>Presumably these resources could also be located via other means (links
>from a corporate intranet web site, group homepage, etc.). As long as a
>client provides a way for a user to enter in the location of a calendar
>the issue is somewhat moot. I do support the notion of automatic /
>programmatic location of calendar resources, however I don't believe that
>it necessarily entails the creation of a new report type.
>You are completely correct in that DASL is general enough to support this
>use case - can you explain why you believe that the report approach is
>somehow better? IMHO, using DASL for calendar resource discovery makes
>perfect sense and wouldn't put an inordinate amount of load on a server,
>considering that the discovery process would only happen infrequently at
>worst and only a few times per user / client at best (on a given server).
>Ietf-caldav mailing list
>Ietf-caldav at osafoundation.org
Interested Bystander, Non-Inc.
More information about the Ietf-caldav