Subject: Re: No comments on my proposals?

From: "PATRICE.LAPIERRE" <[email-masked]>
Date: Tue, 6 Aug 2002 03:29:06 -0800 (GMT-08:00)

On Mon, 2002-08-05 at 13:01, Andrea Campi wrote:
> ... 
> Anyway: if anybody supports the idea, great, otherwise I will stop
> promoting it and just name my queries in an unlikely way...
> 

Hi Andrea,

If I understand correctly, the purpose of the proposition
is to remove the ambiguity present when referring to a stored 
VQUERY having a non-unique QUERYID within the CS.

I agree that removing the ambiguity is important. However 
I don't think that we need to introduce a new namespace to 
achieve this goal. 

A VQUERY may be stored in either the VCALSTORE or a 
VAGENDA. Your proposition could be modified to use the 
container as a namespace. 

i.e., The ambiguity could be removed by:

  1. Enforcing the uniqueness QUERYID within its
     container (not the whole CS).

  2. When referring to a stored VQUERY the container, 
     where it's located, must be specified (otherwise the 
     VCALSTORE is assumed).

e.g.,

   BEGIN:VCALENDAR
   VERSION:2.0
   CMD:SEARCH
   TARGET:relcalid-where-to-search
   TARGET:another-relcalid-where-to-search
   BEGIN:VQUERY
   QUERYID:foo
   TARGET:relcalid-where-the-vquery-is-stored
     ; TARGET could be a parameter of QUERYID if people prefer.
   END:VQUERY
   END:VCALENDAR
  
--
Patrice.

---

From: Doug Royer <[email-masked]>
Date: Tue, 06 Aug 2002 10:23:22 -0600

>      container (not the whole CS).

It would help solve the uniqueness problem for owners
of the container. But as I understand the issue, it would
not solve all of the other issues (CUA's may have to
still keep N number of QUERYID's mappings). It sounds like a good
idea to me. And it gets the spirit of  Andrea's idea
and adds a way to ensure uniqueness.

>      where it's located, must be specified (otherwise the

I could go with TARGET as a parameter, but some get
upset when a property and parameter have the same name.
So, I would lean towards adding TARGET as a property
in VQUERY.

---

From: Andrea Campi <[email-masked]>
Date: Tue, 6 Aug 2002 19:16:16 +0200

> VQUERY having a non-unique QUERYID within the CS.

Not really, my purpose it to avoid conflicts between vendors calling similar
(But not necessarily identical) queries in the same way. I wouldn't want to
lose uniqueness!

> I don't think that we need to introduce a new namespace to 

I only propose introducing a new parameter, actually...

>      where it's located, must be specified (otherwise the 

In practice this is the same as I was proposing but I guess your
version is cleaner.
I also agree with Doug that we should avoid calling a parameter
like a property, but at the same time I wouldn't use a TARGET
property for this (right now TARGET has a very clear semantic) -
the container this query is defined in is definitely a parameter.

What if it was a parameter called SOURCE?

   BEGIN:VCALENDAR
   VERSION:2.0
   CMD:SEARCH
   TARGET:relcalid-where-to-search
   TARGET:another-relcalid-where-to-search
   BEGIN:VQUERY
   QUERYID:SOURCE:relcalid-where-the-vquery-is-stored:foo
   END:VQUERY
   END:VCALENDAR

Anywhere, I'm not going to argue on name or parameter vs property.
What matters to me is that this solves my problem (which is not only
mine I see).

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: Patrice Lapierre <[email-masked]>
Date: 06 Aug 2002 13:35:26 -0400

> (But not necessarily identical) queries in the same way. I wouldn't want to

Understood.

> What if it was a parameter called SOURCE?

I agree.

--
Patrice.

---

From: Doug Royer <[email-masked]>
Date: Tue, 06 Aug 2002 12:35:40 -0600

Andrea Campi wrote:
> Not really, my purpose it to avoid conflicts between vendors
> calling similar (But not necessarily identical) queries in the same
> way. I wouldn't want to lose uniqueness!

I am not sure that adding TARGET to the VQUERY solves your
issue. Two CUA vendors could still create a QUERYID 'my-favorite'
and we solved nothing.

> I only propose introducing a new parameter, actually...

Called NAMESPACE :-)

And it only adds another possible ambiguity. For example
my company is INET-CONSULTING, and I frequently use 'INET'
as a shorthand. I noticed that your company is 'inet.it',
so I suspect you might also use 'INET'. We solved nothing.

> the container this query is defined in is definitely a parameter.

In both cases TARGET means container. One for the QUERYID
and one for the CMD. Looks like the same usage to me.

> What matters to me is that this solves my problem (which is not only

Does it solve the problem? Two vendor CUA could still randomly
select the same QUERYID in the same container (my CUA from work
selected by my employer, and my CUA at home). 

In both cases (NAMESPACE or TARGET) the only thing we did was
specify where the QUERYID is located. It does not solve the
ambiguity problem. CUA's sill might not be able to use
any QUERYID they choose to use.