Subject: Re: (#2) Byte reduction in BEEP commands.

From: "John Stracke" <[email-masked]>
Date: Tue, 12 Feb 2002 10:32:44 -0500

>BEGIN:VCALENDAR
>METHOD:REQUEST
>BEGIN:VEVENT
>...
>END:VEVENT
>END:VCALENDAR
>is stored as:
>BEGIN:VEVENT
>METHOD:REQUEST
>...
>END:VEVENT

Wait a minute--what happens if the iTIP VCALENDAR contains more than one 
component (e.g., a VEVENT and a VTIMEZONE)? How are they kept together?

/===============================================================\
|John Stracke                    |Principal Engineer            |
[email-masked]   |Incentive Systems, Inc.       |
|http://www.incentivesystems.com |My opinions are my own.       |
|===============================================================|
|"Baldric, how did you manage to find a turnip that cost 400,000|
|pounds?" "Well, I had to haggle." --Blackadder III             |
\===============================================================/

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 10:58:29 -0500

> component (e.g., a VEVENT and a VTIMEZONE)? How are they kept together?

And what happens with recurring VEVENT with exceptions?

  BEGIN:VCALENDAR
  METHOD:REQUEST
  BEGIN:VEVENT
  UID:abc123
  RRULE:...
  ...
  END:VEVENT
  BEGIN:VEVENT
  UID:abc123
  ... exception 1...
  END:VEVENT
  BEGIN:VEVENT
  UID:abc123
  ... exception 2...
  END:VEVENT
  END:VCALENDAR

Which VEVENT ends up with METHOD:REQUEST in the CS?

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 09:31:15 -0700

> component (e.g., a VEVENT and a VTIMEZONE)? How are they kept together?

Execelent point. But I think it is more accurate to say:

CAP does not specify how a CS stores data. Which makes that
example a bit mute. We only agree how to exchange information
and not how to store it.

CS - Here is the data as the WG list aggreed to exchange it, 
     now stote it.

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 09:46:21 -0700

> Which VEVENT ends up with METHOD:REQUEST in the CS?

It is not up to CAP to specify how the CS stores the data.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 12:52:09 -0500

> It is not up to CAP to specify how the CS stores the data.

Then, given that the VEVENT quoted above has been created
in the CS.  What would be returned for the following VQUERY
component:

1- BEGIN:VQUERY
   QUERYNAME:Query-01
   QUERY:SELECT * FROM VEVENT
    WHERE METHOD = 'REQUEST'
   END:VQUERY

2- BEGIN:VQUERY
   QUERYNAME:Query-02
   EXPAND:TRUE
   QUERY:SELECT * FROM VEVENT
    WHERE METHOD = 'REQUEST'
   END:VQUERY

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 11:39:43 -0700

>    QUERY:SELECT * FROM VEVENT

I would never ask for expanded un-booked iTIP objects. I would
ask for all iTIP objects and then merge them in the CUA, then
deposit the result in the CS, then delete all merged
un-booked objects.

They would both return the same data except the EXPAND:TRUE
results would contain more and those would contain RECURRANCE-ID's.

So the result would be as provided in the example at the top of
this email (as supplied to the CS), or each one BEGIN/END
VCALENDAR would be returned separately as we (I think) agreed
would be valid.

So they would both return

   (as supplied to the CS above - by whoever asked the question)
   [and optional with more instances that included RECURRANCE-ID]

OR

  (beep ANS 1)	
   BEGIN:VCALENDAR
   METHOD:REQUEST
   BEGIN:VEVENT
   UID:abc123
   RRULE:...
   ...
   END:VEVENT
   END:VCALENDAR

  ...

  (beep ANS n (or NUL for the last?))
   BEGIN:VCALENDAR
   METHOD:REQUEST
   BEGIN:VEVENT
   UID:abc123
   ... exception 2...
   END:VEVENT
   END:VCALENDAR

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 17:15:12 -0500

> VCALENDAR would be returned separately as we (I think) agreed

Ordering would be lost if they were returned separately.

>   (beep ANS n (or NUL for the last?))

1- That's not what one is lead to believe in reading draft-05
   or draft-06:

>  An incoming event (indicated by the value of the "METHOD" property)
>  then appears in relcal2 and relcal3, with the following data:
>
>              BEGIN:VEVENT
>              METHOD:REQUEST
>              UID:abcd12345
>              DTSTART:19990307T180000Z
>              DTEND:19990307T190000Z
>              ORGANIZER:cap://cal.foo.com/relcal1
>              ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c
>               om/relcal2
>              ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c
>               om/relcal3
>              SUMMARY:Important Meeting
>              END:VEVENT

2- It would seem that you are making assumptions on how the CS
   stores the data.  You are telling me that my VQUERY that
   selects VEVENT components that have the METHOD property
   set to 'REQUEST', would return me VEVENT with no METHOD
   property.  Quite surprising at the very least!

3- Let's look at another example.  Given:

   BEGIN:VCALENDAR
   METHOD:REQUEST
   BEGIN:VEVENT
   UID:abc123
   RRULE:...
   ...
   END:VEVENT
   BEGIN:VEVENT
   UID:abc123
   LOCATION:Montreal
   ... exception 1...
   END:VEVENT
   BEGIN:VEVENT
   UID:abc123
   LOCATION:Toronto
   ... exception 2...
   END:VEVENT
   END:VCALENDAR

What would be returned for the following VQUERY components:

a) BEGIN:VQUERY
   QUERYNAME:Query-01
   QUERY:SELECT * FROM VEVENT
    WHERE LOCATION = 'Montreal'
   END:VQUERY

b) BEGIN:VQUERY
   QUERYNAME:Query-02
   EXPAND:TRUE
   QUERY:SELECT * FROM VEVENT
    WHERE LOCATION = 'Montreal'
   END:VQUERY

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 16:15:10 -0700

> Ordering would be lost if they were returned separately.

Why? - BEEP serialize data in the order it was provided.

And there is NO ordering in iTIP objects outside of their own contents.
That is why SEQUENCE and UID exist inside objects. So each VEVENT
MUST contain that information. If they were received out of order,
iTIP tells you how to reassemble them anyway.

> 1- That's not what one is lead to believe in reading draft-05

I am one also - an I belive :-)

>     WHERE LOCATION = 'Montreal'

You would get the entire contents of UID 'abc123', together
or in separate BEEP payloads.

>     WHERE LOCATION = 'Montreal'

You would get the entire contents of UID 'abc123', together
or in separate BEEP payloads expanded into its instances.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 18:41:12 -0500

> or in separate BEEP payloads.

At this point we can't guess what you mean exactly.
Can you specify the VCALENDAR you think would be
returned?

> or in separate BEEP payloads expanded into its instances.

Ditto.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 17:59:33 -0700

> Can you specify the VCALENDAR you think would be

The same as the data initially supplied in your example.
-If you put in in that way, you should get it out
that way.

As to multiple replies:
I was not the one that proposed that a reply can be
in multiple ANS messages. I am just agreeing that it
can be.