Subject: Re: capreq questions - CalID

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Sun, 22 Nov 1998 18:57:17 -0800 (PST)

> From: "Mark D. Anderson" <[email-masked]>
> 
> >Different calendars can not have the same CalID, as
> >then the CalId would not be unique.
> >
> >Is that your question?
> 
> No, an ID i understand, assuming they are basically URI's.

Okay - a CalID.

> Where I'm getting thrown off is the term "hierarchical name".
> Is that a composition of "Name" property values?

Yes - and it is not yet defined how it is composed.

> Or is that a CalID, with no human readable parts?

It can be. There was strong requests for the CalID to
be seperate from the name of the calendar.

> Can I tell just by looking at a CalID that two calendars
> have a hierarchical relationship?

Not necessarily.

> What are the syntactic rules for creating a "hierarchical name"?
> Are these supposed to be like IMAP mailboxes (rfc2060)?

The syntactic rules are not yet undefined.

Humans compartmentalize things. Sub-calendars were meant
to be conceptually the same as file system directories.

> If so, I might note that IMAP dictates that a delete does
> *not* affect children (delete of foo does not delete foo.bar).

You can have an empty directory - but if the directory does
not exist, it can not have children. That was the thoughts
in capreq.

> I would think that there would be a notion of an ID for
> components or calendars, which is essentially an opaque
> string or number, and impervious to naming changes or language
> variants, and that the protocol would concern itself with
> only those ID's.

For a calendar, that's a CalID.

For a component, some want CalID + UID.
I am happy with that.

I agree with you. Hierarchical names introduce locale issues.
That's why the calendar name property exists. Its value I would
hope will be 'text' type, allowing the 'LANG' parameter.

> (And btw, I would think that there could be fully-qualified
> CalID's identifying the same calendar, under replication?)

 (NOTE: HA == High Availability and it is NOT defined in ANY of the
 iCalendar docs. Its just a CS implementation issue. HA is when
 two or more system share the same host name and IP address in
 support of failover or load sharing)

A CalID is a yet to be defined URL. URLs contain host names.
So it would not be possible that two calendars even if one were
an exact copy of the other could ever have the same CalID on
different hosts. And if they were on the same host, the CalIDs
would have to be different or how could you uniquely identify them?

If they did have the same CalID (such as in HA), then they would be
the same calendar and it would be up to the CS implementation to keep
the contents the same. And to a CUA, there would only be one calendar
with its unique CalID. Again this is not defined in any of the
iCalendar docs as it is an implementation issue, not an object
or protocol issue.

Replication as I sent out in another email, is not the same
as LDAP replication. LDAP replication is a means to share
the same information. Calendar replication may be done to
transfer the information to a disconnected host. Or for
implementing a HA CS.

In the case of a disconnected client, you have two calendars
that synchronize to each other from time to time. Two CalIDs.

For a HA CS, you would have some number of calendars that
appear to be the same calendar. One CalID.

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/dougr.html
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: "Mark D. Anderson" <[email-masked]>
Date: Sun, 22 Nov 1998 20:21:03 -0800

>appear to be the same calendar. One CalID.

What I'm a bit uncomfortable with is reliance on a DNS host name
in a fully qualified CalID (or maybe i misinterpret).
I think something like that will certainly be needed, and for
rev 1 may be all that can be accomplished.
But I would imagine that some calendars will function as URNs
(like an ISBN number, if you don't follow http). That does
incur an extra discovery/configuration step to find a physical server, which
will be unacceptable in many cases, but may be a blessing in
others. In the same way, a news: URL is special in that it
does not specify a host name; that is configured separately
in the nntp client. The same issues come up for the web;
see www.purl.org .

Having this separation may ease migration to new servers in 
intranets, as well as supporting replicated stores for load
balancing or other reasons (security, latency, etc. -- HA is
a different matter, as you point out).

-mda

---

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Sun, 22 Nov 1998 20:56:25 -0800 (PST)

> To: <[email-masked]>
> Subject: Re: capreq questions - CalID
> Date: Sun, 22 Nov 1998 20:21:03 -0800
> 

The plan is that a "Qualified Calendar Identifier" its an URI,
therefor has a host name.

> in the nntp client. The same issues come up for the web;

A CS will need to be locatable by the CAP name only. If you
are going across the internet - how will you find the CS
without it? You can configure a CUA to know where to
find a default CS. It then can use only a relative calendar
identifier which does not contain a host name or address. See section 2.

	Relative Calendar Identifier
	Qualified Calendar Identifier

-Doug