Fw: [CalendarServer-dev] Bug related to Example 7.8.6 in the RFC

[Michael Rasmussen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry, should have been to the list.

Begin forwarded message:

Date: Fri, 4 Apr 2008 15:52:34 +0200
From: Michael Rasmussen <mir at datanom.net>
To: Helge Heß <me at helgehess.eu>
Subject: Re: [CalendarServer-dev] Bug related to Example 7.8.6 in the
RFC


- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Helge,

On Fri, 4 Apr 2008 01:53:12 +0200
Helge Heß <me at helgehess.eu> wrote:

> 
> I have the impression that you use the term 'collection' a bit  
> inappropriately.
Well, collection was used as an "abstract class":-)

> A (WebDAV) 'collection' does not have an etag (it can have a ctag,
> but thats Apple specific, not CalDAV).
> It can also have an ics resource representation which then can have
> an etag (when you query it using GET, but this is not really CalDAV
> or collection related).
> 
I no. The main idea is this:
1) I want to be able to retrieve any resource related to a specific ACL
for the shake of been able to share calendar resources in a generic way.
2) A VEVENT is not required to store information about its specific
ICal resource, but following the CalDAV specification any VEVENT is
required to store its UID which must be unique.
3) Having a specific VEVENT means access to its unique UID by which it
is possible to get the associated ETag with this specific iCal
resource.
4) According to the CalDAV specification the ETag is required to be
able to modify and/or delete an iCal resource. 

> Just use
>    <C:text-match>20080404t182145z-123401 at example.com</C:text-match>
> for now (per spec this will default to "i;ascii-casemap").
> 
Yes, of course:-) Thanks.

> 
> I guess this didn't come up before because clients usually query  
> servers by URL, not by UID. Which I personally prefer anyways (why
> do you use the UID in the first place?).
> 
As explained above. You cannot be certain that you know the URL. Many
clients store the specific resource name and combining this with the
URL to the collection, you have the URL. You can be certain that you
know the UID since by specification any resource must save it in a
guarantied unique manor.

- - -- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
- - --------------------------------------------------------------
Debian Hint #7: You can use the cron-apt package to do automatic nightly
downloads of updates for packages installed on your system.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH9jKiQQOPluUB9RwRAidKAJ0Z1E9Xb7hPItn5UrsJgps4iQDnLQCfUHDs
k65HMLzc1JDIEaU2VRHGUYs=
=oMZV
- -----END PGP SIGNATURE-----


- -- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
- --------------------------------------------------------------
Don't get to bragging.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH9jbRQQOPluUB9RwRArTuAKCWr7dsroWAZ/XQ4yYBLqIlpkjKiACglvsx
eB2FHcbGVJy8r92y2RRZzfU=
=7E0U
-----END PGP SIGNATURE-----