Here are some problems using a '/' to represent calendar hierarchy:
1) Force the server designer to use a specific calendar hierarchy.
It imposes a folder like hierarchy of calendars similar to file
diretories.
If the designer used a database for storing calendars, there is
no meaning to the slashes. Calendar hierarchy should be specified
ONLY through the parent and child-list properties.
2) Exposes the calendar hierarchy to clients.
The server may not want to expose the calendar store's hierarchy just to allow access to a calendar. However, if a '/' was used to meaning a level of hierarchy, then I would have to expose the entire path to allow access to a calendar.
Suppose calendar "ghi" is a child of calendar "def",
which is a child of calendar "abc".
Thus the URL to access calendar "ghi" would be
http://calendar.x.com/abc/def/ghi.
The URL exposes the hierarchy of calendar "ghi" to the user.
A user should NOT know the hierarchy of a calendar just to access
it.
Steve Mansour wrote:
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