Subject: Re: capreq questions - Name and ID's

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

> From: "Mark D. Anderson" <[email-masked]>

> >6. Name and ID's
> >
> >CDID uniquely identifies a calendar in a calendar store,
> >whether that calendar is a "top-level" or "sub-calendar"
> >and operations are conducted using a CSID, not using the
> >calendar Name.

> Huh? 4.4 says that CAP MUST specify "how hierarchical name [sic]
> can be used for all operations ... any functionality which
> could be done on a component or calendar by specifying the component ID or 
CSID,
> MUST also be available by specifying the hierarchical name."

It also says. "This is an open issue" (meaning unresolved).
Some want all operations to be able to use the hierarchical name,
others think that the CSID is sufficient.

> How is the "hierarchical name" related to the Name property?
> Do components have hierarchical names (as implied above),
> or only calendars and calendar stores? 

I don't think it was discussed if components could have names. The capreq
doc names were meant to mean calendars and sub-calendars.

It was discussed an I don't think included that a component
have some kind of identifier. Some think that the CSID + UID
would suffice. (Or perhaps hierarchical name + UID). This
is also an open issue.

The relationship between a calendars name and it hierarchy
might be EXAMPLE:

	A calendars name property may be "BASEBALL", yet it might
	exist under (thus a sub-calendar) a calendar with a name
	of "MY PRIVATE CALENDAR".

	Another calendar may have a name property of "BASEBALL"
	under a calendar named "MARK".

The two "BASEBALL" calendars only share a property that happens
to have the same value for the property.

Their "hierarchical name", *might* be, EXAMPLE:

	"MY PRIVATE CALENDAR", BASEBALL

	MARK, BASEBALL

NOTE: The hierarchical delimiter (',' in my example) is NOT yet defined.

> Why does the protocol need to muck around with addressing by
> those pretty human readable names (which as you point out
> aren't unique anyway, because of language variants)?

Because that's the way humans remember things.

> And who says a hierarchical name is readable anyway....

And would a CSID of fo2e323342 be readable?

The intent was the yet undefined name property be human readable to the
person that created it and perhaps to the humans intended to use it.

PERSONAL NOTE:

Its my guess that those that want to access calendars by a hierarchical
name for all operations do not need or want CSID's as they plan
to use the hierarchical name in the same way as a CSID. Others
need to interface to legacy systems that see a name as a property
of a calendar and not as its identifier.

-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 18:15:55 -0800

It is getting a little clearer. Our messages are overlapping;
we might as well be using a chat system :).

>And would a CSID of fo2e323342 be readable?

The UI should certainly have lots of freedom in presenting the
information. Mail clients don't show me message UID's, yet they
are used in protocol.
At a *protocol* level, having an immutable id seems like a natural thing.
(IMAP actually has *two* non-readable identifiers, a UID and a message sequence number...)

>of a calendar and not as its identifier.

Users may want to choose among multiple server-specified names (i18n),
or use their own names, and/or use a different hierarchy.
All that presentation stuff shouldn't change the identifier.

legacy systems which will just gateway CAP to a system which
essentially uses a file system hierarchy as the identifier namespace
will not be able to offer that degree of freedom to users, unless
they use some thick client with proprietary local preference data.

Speaking of which, I didn't see much (any?) discussion of what sorts
of per-user data may be maintained by the server.

-mda