RE: Delimiter characters in relativeCalUID

["Lowde, Chris A" <lowdeca@xxxxxxxxxx>]

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:lowdeca@texaco.com
tel:+1(713)432-2901

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


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.

-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: sman@netscape.com [mailto:sman@netscape.com]
> 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:
> >
> > > Bruce_Kahn@iris.com 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