Subject: [calsify] Persistent UID?

From: "Tim Hare" <[email-masked]>
Date: Tue, 9 Jun 2015 21:29:50 -0400

This came up on the caldeveloper list.   Someone's client is downloading
events, and the events change UID with each download;  I am guessing the
UIDs are regenerated each time the file is created.   I looked at RFC 5545
and didn't see any requirement for persistence of a UID for a particular
VEVENT or other calendar object.   Is this something that should be
addressed?  At the very least should there be a statement that the UID for a
calendar component SHOULD persist for the life of the event?

Tim Hare
Interested Bystander, Non-Inc.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Jun 2015 06:46:51 +0200

Hi,

On 6/10/15 3:29 AM, Tim Hare wrote:
>
> This came up on the caldeveloper list.   Someone's client is
> downloading events, and the events change UID with each download;  I
> am guessing the UIDs are regenerated each time the file is created.
>   I looked at RFC 5545 and didn't see any requirement for persistence
> of a UID for a particular VEVENT or other calendar object.   Is this
> something that should be addressed?  At the very least should there be
> a statement that the UID for a calendar component SHOULD persist for
> the life of the event?
>
>

That's just bizarre.  Anyone know their logic?

Eliot

---

From: Arnaud Quillaud <[email-masked]>
Date: Wed, 10 Jun 2015 08:57:52 +0200

On Wed, Jun 10, 2015 at 3:29 AM, Tim Hare <[email-masked]> wrote:

> addressed?  At the very least should there be a statement that the UID for
> a calendar component SHOULD persist for the life of the event?
>

Well, as far as I can see, it is there in the  definition of the UID
property itself:

<<

   Purpose:  This property defines the persistent, globally unique
      identifier for the calendar component.

>>  (https://tools.ietf.org/html/rfc5545#section-3.8.4.7)

Arnaud Quillaud

> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
>
>

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 10 Jun 2015 09:50:41 -0400

Hi Tim,

--On June 9, 2015 at 9:29:50 PM -0400 Tim Hare <[email-masked]> wrote:

> addressed?  At the very least should there be a statement that the UID
> for a calendar component SHOULD persist for the life of the event?

One of the things CalConnect is working on is a "developer's guide" 
document that will cover a lot of "best practices" (such as maintaining a 
persistent UID), as well as explanation of some of the iCalendar features 
that often trip people up (obvious ones being time zones and recurrences). 
Some of that could certainly feed into any future updates to iCalendar that 
the IETF does.

-- 
Cyrus Daboo

---

From: Steve Allen <[email-masked]>
Date: Wed, 10 Jun 2015 07:13:29 -0700

On Wed 2015-06-10T09:50:41 -0400, Cyrus Daboo hath writ:
> >UIDs are regenerated each time the file is created.

I was guilty of this for events generated by a webserver from a
database.  The toolkit for constructing VEVENT objects added its own
UID if that method was not invoked.  I would never have noticed if I
had not seen my calendar client running slow enough to see the
repainting of every event.  I fixed after identifying suitable primary
keys and date stamps from the records where the components of the
event are stored.

> document that will cover a lot of "best practices"

+1

--
Steve Allen                 <[email-masked]>               WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046          Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/    Hgt +250 m