Subject: Re: Delimiter characters in relativeCalUID

From: [email-masked] (John Sun)
Date: Thu, 01 Apr 1999 10:28:43 -0800

There are many problems with using a '/' were used to represent a
calendar hierarchy.
In fact, imposing any semantic definition to unique identifier has many
problems.

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: [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

---

From: [email-masked] (John Sun)
Date: Thu, 01 Apr 1999 10:27:18 -0800

There are many problems with using a '/' were used to represent a calendar
hierarchy.
In fact, imposing any semantic definition to unique identifier has many problems.

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.

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.

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
>
> > 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
> > 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,
> > > > Why?  You aren't suggesting a delimiter character are you? That would
> > > Even if we don't have structure today, a delimiter permits us to *add*
> > 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

---

From: John Stracke <[email-masked]>
Date: Thu, 01 Apr 1999 21:11:51 +0000

> 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 |
\=============================================================/

---

From: [email-masked] (Steve Mansour)
Date: Thu, 01 Apr 1999 16:07:01 -0800

> don't have any '/'s in your calendar IDs.

The only concern I would have about making that sort of a claim is that it
will cause interoperability problems for mixing and matching clients and
servers. For example, one client thinks that the '/' means hierarchy. The
server it talks to assigns no special meaning to '/'.

> namespace, and there won't be any safe way to build a string that

This is a slippery slope. Either they are an opaque string or they are
not.  If we start by making it an opaque string and add semantics later we
will almost certainly encounter problems.

-Steve

---

From: [email-masked] (Richard Shusterman)
Date: Fri, 02 Apr 1999 12:07:27 -0800

> characters into relativeCalUID or should it be an opaque string?  Speak up.

Maybe I'll get the last word on this subject :)

I looked over rfc 2396 (defines URI) and it already recommends the following:

- Reserved Characters (see section 2.2)
- Unreserved Characters (see section 2.3)
- Excluded US-ASCII Characters (see section 2.4.3)

Note that "/" is in the list of recommended reserved characters and <CR><LF> in
excluded characters. It also mentions that these lists of reserved characters,
unreserved characters, and excluded characters as well as hierarchy and case
sensitivity are left up to the definition of the URI schemes.

As Bruce pointed out, I think there is a good argument for definining this grouping
of characters (reserved, unreserved, and excluded) for both iRIP and CAP. This will
allow for simpler URI parsers and avoid interoperability problems between
implementations. As for charset, this rfc says "in the simplest case, the original
character sequence contains only characters that are defined in US-ASCII" and that
"it is expected that a systematic treatment of character encoding within URI will
be developed as a future modification of this specification. Using the KISS
philosophy, we should stick to the US-ASCII charset for our URI schemes.

As for delimiter characters, this is not needed since we already have parent/child
properties of a calendar. As Doug pointed out, it is a security hole to allow
parent/child relationships in URI names, which bypasses the security checks that
protect the parent/child properties of a calendar.

We should not confuse the publishing of calendars as documents (or files) with
referencing calendars in iRIP or CAP. In a document URI scheme like http://, it
makes sense to navigate a file system using the URI name. However, it would be a
mistake to imply that an iRIP or CAP server implements a file system hierarchy for
navigating it's calendars. More than likely, these servers will use databases to
store these calendars. If a client needs to discover it's children or parent, it
should request and receive (subject to access control) the calendar properties
associated with the URI.

I propose that the iRIP and CAP editors tighten up their definitions of
relativeCALID to include a list of reserved characters, unreserved characters, and
excluded characters, to specify US-ASCII as the only charset for relativeCALID, and
that no hierarchy or case sensitivity is required in a relativeCALID.

Richard

---

From: John Stracke <[email-masked]>
Date: Mon, 05 Apr 1999 16:05:18 +0000

> server it talks to assigns no special meaning to '/'.

That is exactly the kind of interop problem that I'm trying to *prevent*.  At
some time in the future, somebody will want to have an ID string with
heirarchy in it, and it's going to be easier if we don't grab the entire
namespace now.

> will almost certainly encounter problems.

My point exactly.