Registration open for Calconnect Roundtable and Interop Testing Event, September 2005 - The Calendaring and Scheduling Consortium

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Errata on Calconnect Roundtable and Interop Announcement for September 2005

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/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
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Re: caldav global addressbook

Hi Kervin,

--On August 8, 2005 12:14:41 PM -0400 "Kervin L. Pierre" 
<kervin <at> adevsoft.com> 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
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Re: caldav global addressbook

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 <at> .*</D:match>

Regards,
Kervin
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Re: caldav global addressbook

Hi Kervin,

--On August 8, 2005 2:24:42 PM -0400 "Kervin L. Pierre" 
<kervin <at> adevsoft.com> 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
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

xCal - resubmitted.

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 xCal <at> INET-Consulting.com

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

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Re: xCal - resubmitted.

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 xCal <at> INET-Consulting.com
> 
> 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

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

RE: [Ietf-caldav] xCal - resubmitted.

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

	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='request'" might have an extension of .xrc while a published
calendar "method='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.

Re: 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 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! 
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. 

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

> 	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='request'" might have an extension of .xrc while a published
> calendar "method='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 
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: reinhold <at> kainhofer.com, 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

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav