Subject: No comments on my proposals?

From: Andrea Campi <[email-masked]>
Date: Fri, 2 Aug 2002 22:39:56 +0200

Hi all,

I received no answer to the proposals I made in my email of Jul 17 
(http://www.imc.org/ietf-calendar/mail-archive/msg05880.html). Were they 
missed or do you feel they are not interesting?

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Fri, 02 Aug 2002 15:00:42 -0600

> missed or do you feel they are not interesting?

See:

	http://www.imc.org/ietf-calendar/mail-archive/msg05975.html

---

From: Andrea Campi <[email-masked]>
Date: Fri, 2 Aug 2002 23:28:31 +0200

> 	http://www.imc.org/ietf-calendar/mail-archive/msg05975.html

Uhm... yes I saw that, but under the ALLOW-CONFLICT comment there was a 
lot more... The proposal for NAMESPACE and NATIVE parameters, etc...

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Fri, 02 Aug 2002 17:51:48 -0600

> lot more... The proposal for NAMESPACE and NATIVE parameters, etc...

NAMESPACE:

CARID's are not authoritative. By that I mean they could
be just sequentially numbered. They have no other meaning
other than being unique to the CS. If there is a conflict,
just pick a new CARID.

NATIVE    - Where you say:           

> Description: A server may choose to implement some stored
> queries in the most efficient way, which may not be easy to express
> in CAL-QL-1. A server may also choose to do this in order to avoid
> having to parse and compile CAL-QL-1 queries in its native query
> language.

As all iCalendar objects (we believe) can be represented
and restricted with the VCAR model in CAP. The only thing
left would be vendor extensions. And we allow the (x-)
experimental extensions now that vendors can use.

A CS could be written that tells you what its VCARs are while
at the same time not be able to parse any. They could be
compiled into a ROM and the CS just sends them. One of which
could be to disallow any addition, deletion or modification of
any VCARs (all decreed). So that CS would never need to
parse a VCAR. The rules could be compiled into the CS and
the VCARs it sends back could just be a string of text
to the CS. One or more VCARs could be hard coded.

---

From: Andrea Campi <[email-masked]>
Date: Mon, 5 Aug 2002 09:54:45 +0200

> other than being unique to the CS. If there is a conflict,

I might have been unclear, sorry. I was referring in general to queries, but
I was thinking of the SEARCH command in particular.
Think of this scenario: a client could conceivably use stored queries for most
if not all of its needs (that's why we have stored queries at all, right?).
The client needs to know the queries are there, so they must be there and have
the name it expects, not just any unique name. If vendors start to add stored
queries, we can't expect everybody to uniquely name things so that they don't
conflict, or if they do, they don't have slightly different semantics.
Besides, the only way a client can be sure to find their stored queries is to
install them; if a conflict arise during installation, it's not easy to just
change name.

Do you agree there's a problem there? If you do, do you have any other solution
besides what I propose? Otherwise I can't see how QUERYID is going to be of
any use in improving, instead of reducing, interoperability.

> experimental extensions now that vendors can use.

Again, I wasn't thinking of VCARs, I was thinking of a server which mapped

> to the CS. One or more VCARs could be hard coded.

Yes, you are right, I withdraw my proposal as it would serve no pratical
purpose.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: Doug Royer <[email-masked]>
Date: Mon, 05 Aug 2002 08:49:52 -0600

Andrea Campi wrote:
> I might have been unclear, sorry. I was referring in general to
> queries, but I was thinking of the SEARCH command in particular.
> Think of this scenario: a client could conceivably use stored
> queries for most if not all of its needs (that's why we have stored
> queries at all, right?). The client needs to know the queries are
> there, so they must be there and have the name it expects, not just
> any unique name. If vendors start to add stored queries, we can't
> expect everybody to uniquely name things so that they don't conflict,
> or if they do, they don't have slightly different semantics.
> Besides, the only way a client can be sure to find their stored
> queries is to install them; if a conflict arise during installation,
> it's not easy to just change name.

There are only two kinds of stored queries. (1) Those placed
there by the CS implementation, and (2) those placed there by
a CUA.

It is conceivable that the stored queries placed there by the CS 
implementation are not delectable or modifiable (by VCAR control)
to the CUA. So no matter what the CUA wants, it can not use
those QUERYID's for its own stored queries.

If the stored query is placed there by any CUA the same is true.
The first one that grabs a QUERYID wins. The next attempt
better use an different QUERYID.

> Do you agree there's a problem there? If you do, do you have any
> other solution besides what I propose? Otherwise I can't see how
> QUERYID is going to be of any use in improving, instead of reducing,
> interoperability.

I do not see a problem. I can still store my queries and use
them by ID. And the QUERYID is still just a random unique string.

I do not see an interoperability problem. I think you
are saying that if a CUA were to connect to multiple CS's and
had permission to store queries on each of those CS's, it
would have to keep a map of its queries vs. which CS. A bit
painful, but I do not see that as an interoperability issue.

I guess if others wanted namespaces, we could add it.
In order for namespaces to not conflict with each other,
would we need to setup a registration process? Otherwise
what is to keep the namespaces from stepping on each other?

> queries to an SQL backend. Anyway, see below:

FYI - I map VCARs using an SQL backend.

---

From: Andrea Campi <[email-masked]>
Date: Mon, 5 Aug 2002 19:01:46 +0200

> painful, but I do not see that as an interoperability issue.

Even if a CUA connects to just one CS it needs to track the
queries. With my proposal, the CUA installation process just
stores the queries, the the CUA can as well have them compiled
in.

> what is to keep the namespaces from stepping on each other?

Well, if somebody chose not to use sensible names, yes. Otherwise
I see no need for a registry; I would use my domain name, for
instance.

Anyway: if anybody supports the idea, great, otherwise I will stop
promoting it and just name my queries in an unlikely way...

Bye,
	Andrea