Re: Delimiter characters in relativeCalUID

["Frank Dawson" <fdawson@xxxxxxxxxxxxx>]

On Monday, March 29, 1999 3:56 PM, Steve Mansour wrote, in part:

>OK. Let's put this point to the test. Should we introduce one or more
delimiter
>characters into relativeCalUID or should it be an opaque string?  Speak up.


Definitely, not!

1. This could easily get into one of those long running, waste of WG time
discussions. Remind folks of the 1998 discussions about time formats?

2. The CAP address for a calendar needs to be an opaque string. This will
make it MUCH easier to address moving of calendars, components and
properties. We haven't disected this problem completely. There are probably
some other ill effects of tightly coupling the address to other
characteristics of the calendar. This just smells like bad design to me.
Others? Does Chris Newman's RFC on lessons-learned about protocol design
provide some help here?

3. It is just bad engineering to be tightly coupling semantics that need to
be disjoint. For example, "addressing", "relationships" and names. Some
would argue that the CAP address should expose the "hierarchical"
relationship of different calendars. Others would argue that the CAP address
should expose the displayable friendly name of the calendar. Both are
completely bad ideas. These semantics should be kept disjoint in separate
calendar properties. What happens if you move a calendar within a CS? Does
it's name change? Does it's hierarchical relationship with other calendars
change? Will it's address change? I think that the sequential answer needs
to be "Need Not", "Yes" and "No".

Folks...we had this discussion resolved by having separate calendar
properties: <displayable I18N name>, <parents>, <children> and CalID. Let's
not blow it.

-- Frank