Re: Delimiter characters in relativeCalUID

[rans@xxxxxxxxxxxx (Richard Shusterman)]

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.
>

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