Subject: Re: Delimiter characters in relativeCalUID

From: "Frank Dawson" <[email-masked]>
Date: Mon, 29 Mar 1999 17:39:43 -0500

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

---

From: "Lowde, Chris A" <[email-masked]>
Date: Tue, 30 Mar 1999 08:35:42 -0600

You have nothing to lose by defining the charater today and it is easier to
define a delimiter now than to try to define one in a future version when
some one may have already used the character in what was a valid string.

Chris Lowde
Texaco
mailto:[email-masked]
tel:+1(713)432-2901

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 29, 1999 14:44
To: Lisa Lippert (Dusseault) (Exchange)
Cc: John Stracke; calsch WG
Subject: Delimiter characters in relativeCalUID

-Steve

"Lisa Lippert (Dusseault) (Exchange)" wrote:

> I haven't been at the CAP authors meetings lately, but that shouldn't
matter
> -- I don't recall seeing a consensus on the list or in the WG meeting that
> the delimiters should not be defined.
>
> Undefined strings are very scary for later versions of the protocol -- we
> will hamstring ourselves for CAP 2 (or later) if we can't easily enhance
> hierarchical functionality in calendaring.  Furthermore, interoperability
is
> threatened if different implementations understand different things from
> different characters.  I'd like to see a character defined as a
hierarchical
> delimiter, even if implementations are not required to support
hierarchies.
> It will be much less painful in the long run if we define the character
now.
>
> We should also be very explicit about other possibly "special" characters
> such as spaces, tildes, and whether they are meaningful, meaningless,
> reserved, must be supported, etc.
>
> Lisa
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 29, 1999 12:21 PM
> To: John Stracke
> Cc: calsch WG
> Subject: Re: IRIP version 4 (Part 1) c
>
> John Stracke wrote:
>
> > Steve Mansour wrote:
> >
> > > [email-masked] wrote:
> > >
> > >> Good choice until that last part.  You should preclude some
> > >> characters like
> > >> '/' or <CR>, etc.
> > >
> > > Why?  You aren't suggesting a delimiter character are you? That would
> > > imply some sort of structure. :-)
> >
> > Even if we don't have structure today, a delimiter permits us to *add*
> > structure later if it turns out to be useful.
>
> We went through that discussion a two of the editors meetings. The general
> feeling is that it's a bad idea to put *any* sort of meaning into these
> strings. Even a delimiter character.
>
> -Steve