Subject: RE: Delimiter characters in relativeCalUID

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Fri, 9 Apr 1999 15:44:04 -0700

Or, even, the server implementor could allow hierarchy in URLs, and just
know that in the flat database any name with '/' in it could still be
treated like an opaque string.

Having calendar "foo" and calendar "foo/bar" and making "foo" the parent of
"bar" (and "bar" the child of "foo") still does not impose storage
restrictions on the implementation.  

We're designing how implementations *appear*, not how they *work*.  

Lisa

> -----Original Message-----
> From: John Stracke [mailto:[email-masked]]
> Sent: Thursday, April 01, 1999 1:12 PM
> To: [email-masked]
> Subject: Re: Delimiter characters in relativeCalUID
> 
> 
> John Sun wrote:
> 
> > Here are some problems using a '/' to represent calendar hierarchy:
> >
> > 1) Force the server designer to use a specific calendar hierarchy.
> 
> No, it doesn't.  If you don't want a heirarchy, you just make sure you
> don't have any '/'s in your calendar IDs.
> 
> > 2) Exposes the calendar hierarchy to clients.
> 
> Aliases.
> 
> Again, I am not saying we should *use* the '/' in CAP1; I just want to
> reserve it (or some other character) for use in a hypothetical future
> version.  Otherwise, CAP1's calendar IDs will gobble up the entire
> namespace, and there won't be any safe way to build a string that
> delimits them.
> 
> --
> /=============================================================\
> |John Stracke    | My opinions are my own | S/MIME & HTML OK  |
> [email-masked]|============================================|
> |Chief Scientist | NT's lack of reliability is only surpassed |
> |eCal Corp.      |  by its lack of scalability. -- John Kirch |
> \=============================================================/
> 
>