Subject: Adding more unique identifiers

From: [email-masked] (Roger D)
Date: Fri, 13 Jul 2001 17:43:33 -0400

The change management component properties in section 4.8.7 seem to be designed for doing data merging at the component level. This is normally adequate, given that an individual VEVENT or VTODO has an ORGANIZER, but it will fail if the ORGANIZER grants permission for someone else to act on their behalf, or if the ORGANIZER uses multiple CUAs (perhaps on multiple desktop machines, or a desktop and a PDA) and changes made in multiple places arrive at the server out of order. As a result, a server and one or more CUAs might wish to implement a more ambitious aim, that of doing data merging at an individual property level. To do this, the first thing that is necessary is to give each component and property a unique identity.

The only component that currently cannot have a unique identifier is a VALARM sub-component (assuming that a TZID on a VTIMEZONE is a globally unique identifier, which is not an entirely safe assumption, and that STANDARDC and DAYLIGHTC sub-components in a VTIMEZONE can be uniquely identified by their DTSTART). I propose that we allow a 
UID property to be added (as an optional property that can occur only once) to any sort of VALARM, and we may wish to consider allowing this on a VTIMEZONE, STANDARC, and DAYLIGHTC as well. We also might wish to strengthen the language of section 4.8.4.7 to at least RECOMMEND that calendar systems generating VALARM component give it a UID.

For properties that can only occur once, no unique identifier is required: their identity is implicitly specified by the uid of the component they are a property of.

However, for those properties that can occur more than once in a component (ATTACH, ATTENDEE, CATEGORIES, COMMENT, CONTACT, DAYLIGHTC, EXDATE, EXRULE, FREEBUSY, RSTATUS, RELATED, RESOURCES, RDATE, RRULE, STANDARDC, TZNAME and X-PROP, and possibly also DESCRIPTION for VJOURNALs), and do 
not already have a unique identifying value (ATTENDEE has the CAL-ADDRESS which must be unique, and arguably EXDATE and RDATE do since their values must be unique), we would need to allow the addition of a disambiguating 
property parameter. I hereby formally propose the following:

To: [email-masked]

Parameter Name: PUID

Purpose: To specify a unique identifier for a property that may occur more than once in a component, to facilitate property level change management.

Format Definition: This property parameter is defined by the following notation:

    puidparam = "PUID" "=" DQUOTE puid DQUOTE
    
    puid = <*QSAFE text forming a unique identifier>

Description: This parameter can be specified on properties that are allowed to exist more than once in a component (even if there is currently only one such property in the component). The value of the "puid" property parameter MUST be a globally unique identifier. The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that 
can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the [5] addr-spec. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of the "@", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number). Using a date/time value on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts should be using the same domain name or IP address at the same time. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can gua!
rantee the uniqueness of the left hand side within the scope of that domain.

For those properties (CATEGORIES and RESOURCES) whose value can be a comma separated list, the PUID applies only to the first element in the comma separated list, and the other elements in the list have no unique identities specified. If a calendar system uses PUID parameters, it should list each individual category as a separate CATEGORIES property and each 
resource as a separate RESOURCES property, avoiding the use of comma separated lists, thus allowing each category or resource to have its own PUID.

This parameter is an important method for group scheduling applications to match properties in requests with those in later replies, modifications or deletion requests. To assure interoperability with other group scheduling applications, calendaring and scheduling applications receiving a component that has PUID parameters on one or more of its properties MUST persist and 
return this parameter in a reply, modification or deletion request on all properties where it is already present, and SHOULD generate this parameter on all additional properties they create for the component in a reply, modification or deletion request. This identifier is normally created by the calendar system that generates an iCalendar property, but if it is absent any calendar system that receives the iCalendar property MAY generate a PUID for it.

Implementations MUST be able to receive and persist values of at least 255 characters for this parameter. 

The following is an example of this property parameter: 

      RESOURCES;PUID="[email-masked]":VCR

--Roger

P.S. We might also wish to suggest the use of BASE64 encoded 128-bit MD5 hashes of a suitable amount of entropy (certainly including the current date and time and the machine's IP address) as a UID, like the Microsoft GUID, as an alternative approach to generating a UID.
__________________________________________________________________
Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/