[Ietf-caldav] CalDAV Global Address Book

[Cyrus Daboo]

Hi Kervin,

--On June 26, 2006 7:51:00 AM -0700 "Kervin L. Pierre" 
<kervin at adevsoft.com> wrote:

>> There are situations where access to the principal
>> hierarchy may be denied
>> entirely (whether directly or by a REPORT). For
>> example, consider an ISP
>
> That is true.  What about department or
> organizational servers?  Is denying authenticated
> users access to the principal hierarchy common?
> Is it some sought of best practise?
>
> If it is not then we can take our chances and
> simply list that permission as a prequisite for
> using the CalDAV global address book.

What's wrong with simply putting calendar attributes in the organization's 
directory? Having a 'special' address book just for CalDAV seems silly, 
when there will likely be a directory that will contain all the other 
useful communication related attributes too (email, im, web page etc). If 
the directory is sufficient, then RFC 2739 defines a set of attributes that 
can be used.

>> Question: is your intent here to have a general way
>> to find anybody's
>> calendar given some identifier?
>
> Exactly.  And to also return a list of everybody
> in the organization ( or more precisely on the
> server ), that has a calendar ( ie. Browse users ).

Again - a proper directory is a better bet.

> Basically how Microsoft Outlook shares calendars...
>
> (i) Type in a term
> (ii) Get a list of principal matches
> (iii) Click on a match to retrieve that calendar
>   Or
> (i) Browse the Global Address Book
> (ii) Select the principal you need
> (iii) Click on their row to retrieve their calendar
>
> Btw. That is probably how most clients are going
> to share calendars, I'd wager.

Well, a client could expose the calendar hierarchy and allow users to 
browse that - that is what I did in Mulberry and matches the UI we had for 
browsing shared mailboxes on the email side. The client can offer searching 
on that if it wanted - no need to go to principals.

>> Do you actually want
>> their calendar as
>> opposed to wanting to do scheduling operations with
>> them (as in free-busy
>> lookups, booking meetings etc)?
>
> We need the calendar, definitely.  This is used
> for delegating calendar duties to secretaries,
> browsing a colleague's schedule, etc.

OK.

>> gone on in Calconnect. Right now the feeling is that
>> there needs to be a
>> new 'scheduleto' URI scheme with appropriate lookup
>> rules (SRV records) to
>> find the calendar service for a particular address.
>
> This seems to be slightly different from what
> we're doing, if I am not mistaken, but please
> correct me if I am wrong...
>
> A SRV record will be useful in providing the
> appropriate CalDAV server given a principle
> or a domain.  Eg. Answering "Where is example.com's
> CalDAV server" with "It's cal.example.com".
>
> But after the client initiates the session
> with cal.example.com, it still doesn't know
> where the user's 'primary' calendar is.
> And it still can't provide the user with a
> list of available principals.  Correct?

The purpose of the SRV is to allow outside users to locate a CalAV server 
that supports the calendar-schedule feature so that they can carry out 
scheduling operations. That does not expose individual user calendars 
within the organization - merely a 'public' URL to which calendar-schedule 
requests can be sent and response returned.

Scheduling like that is more likely to be what people want to do for their 
personal calendars - i.e. not expose those to anyone on the outside but 
allow them to schedule.

Discovery of actual 'public' calendars is a slightly different issue and 
does need to be addressed in some fashion. Various possibilities for that 
have been mentioned, including use of ATOM feeds etc. Of course a similar 
type of problem exists for discovering public mailing lists - that is 
usually addressed by simply having a webpage listing them with links to 
initiate subscription etc.

-- 
Cyrus Daboo