Subject: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03

From: Nathaniel Borenstein <[email-masked]>
Date: Thu, 13 Nov 2003 11:45:05 -0500

The CALSCH WG (really a minor fraction thereof) met in Minneapolis.  
Both WG chairs and the editor of the only open document were absent
(the latter due to Jabber-related technical difficulties) from the
meeting.  At the invitation of Pat Egen, I chaired the meeting.  
Obviously the absence of so many key people made a major decision
inappropriate.  However, there was apparent consensus for considering
several steps that we hope will reinvigorate the WG, and that we are
proposing to the mailing list for wider consideration.

1.  The Changing of the Bobs:  Bob Morgan has volunteered to come in as
WG chair in place of Bob Mahoney, who has been under increasing time
pressure and wishes to step down.

2.  The Changing of the Bards:  I have volunteered to perform One More
Round of edits on the CAP document, with an eye to having a Last Call
for Proposed Standard status by March.  I want to express my gratitude
to Doug Royer for getting the document to the point where the remaining
problems are small enough for me to view that as an easy target date.

3.  The Changing of the Paradigms:  Lisa Dusseault has volunteered to
write a first outline of what a WebDAV-enabled calendar access
mechanism might look like.

4.  The Changing of the Version:  There was general consensus that, CAP
aside, the rest of the ical documents have been around long enough and
had enough implementations that it is time to review and amend them
all.  Accordingly, Bob Morgan has volunteered to draft a new charter
for the WG, and Ned Freed and Nathaniel Borenstein have both
volunteered to work on that next round of document revisions.

I look forward to your comments on these proposals.  -- Nathaniel

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 14 Nov 2003 15:28:35 -0800 (PST)

> pressure and wishes to step down.

For those who may not know me, I am currently co-chair of the ldapbis WG,
which is nearing completion, and have been hanging around IETF and the
apps area since 1989.  I have not been deeply involved in calendar work,
but am somewhat associated with the calendar software implementation going
on here at the University of Washington.  I expect my role, assuming this
change is finalized, will be the process guy.

 - RL "Bob"

---

From: [email-masked]
Date: Sat, 15 Nov 2003 10:25:54 -0500

Thanks for taking on this effort.

---

From: Tim Hare <[email-masked]>
Date: Sat, 15 Nov 2003 21:18:15 -0500

I will have to look up what WebDAV is, but the rest of it sounds OK to 
me.  I wonder if we should also, during our review process, look over the 
RDF calendar work to see where we can improve synergy with those efforts. 
At this point I don't understand RDF/Semantic Web items at a deep enough 
theoretical level but as an old, old, user of markup languages I do "get" 
the benefits of XML and I believe there were folks who took the xCal work 
and tried to extend it into RDF?  XML also would allow RSS "feeds" of 
published calendar info such as schedules.

Tim Hare
Interested Bystander, Non-Inc.

---

From: Libby Miller <[email-masked]>
Date: Sun, 16 Nov 2003 12:43:45 +0000 (GMT)

hi Tim, all,

I've been following these discussions with interest, and was waiting for
an opportunity to (re-)introduce myself. I lead the W3C RDF Interest
group's calendaring taskforce (an informal group), and I'd be very interested
to improve contact with the CALSCH WG.

Within the past year, we have narrowed our remit to providing
documentation and software for roundtripping between iCalendar and its
RDF representation. You might be interested in a summary of our current
mini-process here:

http://swordfish.rdfweb.org/discovery/2003/11/rdfical/final-tidy.html

(that document is a submission to the WWW2004 confernce)

Perhaps the most relevant aspect is that we generate our RDF schema for
iCalendar from test data, and not the other way around. We are therefore
very interested in any sample data that is available.

You can find our sample iCalendar files and the derived RDF files here:

http://www.w3.org/2002/12/cal/test/
http://www.w3.org/2002/12/cal/

cheers,

Libby

---

From: Doug Royer <[email-masked]>
Date: Sun, 16 Nov 2003 13:41:12 -0700

>http://www.w3.org/2002/12/cal/
(A) I have seen these before. Some minor nits:

 Many of the VALARMs have an ATTACH property that is not valid:

        ATTACH;VALUE=URI:Ping

 Extra CR LF's in them between components.

 Some have no METHOD property - does that mean they are booked
 like in CAP?

 Some VEVENTs have no SUBJECT or DESCRIPTION.

(B) RDF issues I have noticed in the examples:

  I noticed that the RDF format drops the 'VALUE' parameter completely.

  The RDF-cal has a 'class' tag, that is not the same as the iCAL 
'class' tag.

  The examples drop the CLASS property nd its PUBLIC, PRIVATE,
  and CONFIDENTIAL values completely.

  The RDF-cal does not distinguish between property values and parameters.
 
  I have yet to see an example of how multivalued values are treated.
  Is the XML tag replicated or is the value just put in 'as is'?

(C) And there is an xCAL mailing list with low volume. It has not been used
      in a while but the archives are online.

    To subscribe send email to [email-masked]' with
    a subject of 'subscribe xcal-dev'.

    Archives at:            http://inet-consulting.com/xcal-dev

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards

---

From: John Stracke <[email-masked]>
Date: Mon, 17 Nov 2003 08:53:20 -0500

Tim Hare wrote:

> I will have to look up what WebDAV is, but the rest of it sounds OK to me.

RFC-2518; http://www.webdav.org

It's a set of extensions to HTTP to manipulate resources on an HTTP 
server: move them around, create/delete them, list/create/delete 
directories, set/get metadata.  There is also work on extending WebDAV 
to support versioning and searching.

-- 
/================================================================\
|John Stracke      [email-masked]                         |
|Principal Engineer|http://www.centive.com                       |
|Centive           |My opinions are my own.                      |
|================================================================|
|A successful tool is one that was used to do something undreamed|
|of by its author.                                               |
\================================================================/

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 17 Nov 2003 13:33:06 -0500

Hi John,

--On Monday, November 17, 2003 8:53 -0500 John Stracke 
<[email-masked]> wrote:

|> I will have to look up what WebDAV is, but the rest of it sounds OK to
|> me.
|
| RFC-2518; http://www.webdav.org
|
| It's a set of extensions to HTTP to manipulate resources on an HTTP
| server: move them around, create/delete them, list/create/delete
| directories, set/get metadata.  There is also work on extending WebDAV to
| support versioning and searching.

Access control is also an extension - obviously that would be important for 
any shared calendar applications. There is also an HTTP SASL extension in 
the works which will add more robust authentication - probably important 
for enterprise calendaring use.

-- 
Cyrus Daboo

---

From: Doug Royer <[email-masked]>
Date: Tue, 18 Nov 2003 13:45:58 -0700

There is a great book on WebDAV.

  "WebDAV: Next-Generation Collaborative Web Authoring"

It gives a great review of HTTP and explains WebDAV in detail.

 Lisa Dusseault is the author.

Tim Hare wrote:

> me.  ...

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 19 Nov 2003 10:35:25 -0700

> problems are small enough for me to view that as an easy target date.

Thanks! I am looking forward to learning from
your experience.

Thank you!

--

---

From: George Babics <[email-masked]>
Date: Wed, 19 Nov 2003 12:29:35 -0500

> pressure and wishes to step down.

   Thank you Bob Mahoney for all your work. Welcome Bob Morgan.

> volunteered to work on that next round of document revisions.

   Very good!

   When may the new charter be available?

> I look forward to your comments on these proposals.  -- Nathaniel

   I feel that these proposals are very positive and that hopefully we
can finally have a last call for CAP.

   I would also like to add, if it is not already implicit in the above
proposals, that the list, i.e., the new chair(s), should try to call a
consensus on issues as soon as it is appropriate. Too often in the past,
we have spent much time discussing issues or even agreeing on solutions,
only to have the discussion die down without a consensus. Later the same
issue would pop up again on the list, and we would often rehash the same
discussion. Moreover, it will allow us to close issues and move on to
other ones.

George

---

From: Tim Hare <[email-masked]>
Date: Thu, 20 Nov 2003 22:03:41 -0500

I think now is a good opportunity to take a quick vote or survey to 
determine what are the critical unresolved issues remaining to get the 
first version out the door, and what are the not-so-critical issues that we 
may or may not want to resolve before last call. As I am a relative 
latecomer to the list, I cannot yet come up with an exhaustive list, but 
here are a few, others can add theirs. Please - let us just list items for 
now without emotion behind them, we need a list, not another argument (and 
I _know_ some of these may still be controversial)

Critical:
   A.	Consensus that the original author's interpretation of recurrence-ID 
handling (quoted here) is or is not what should happen.
	>"3) Considerable discussion was held on semantics and behavior 
of  recurring events during the IETF deliberations leading to 
WG 	>consensus around  the definition of iCalendar. It is our belief that 
the intent of this consensus  is as follows:

	>a) the value for RECURRENCE-ID was agreed to be the date/time  value of 
the original recurrence instance. This value remains 	>unchanged for 
as  long as the base recurrence set (or pattern) exists. A rescheduling of 
an  individual recurrence instance did not 	>cause creation of new base 
recurrence  set, but only moved the start/end of the specified recurrence 
instance.

	>b) An addition of a new recurrence instance to the set would be 
an  example of an action that would create a new recurrence set 	>e.g. 
changing a  Monday weekly meeting to a Monday and Tuesday weekly meeting. 
This latter action  is an example of an action  	>that *might* also cause 
the values of the  RECURRENCE-ID properties for each member of the 
recurrence set to get redefined  	>(*might* is used here and in the RFC 
because it is possible that occurrences in  the new recurrence set will 
have the same 	>date/time value). But a rescheduling  of a member of the 
recurrence set would not cause such behavior (i.e., change  the value) 
of 	the RECURRENCE-ID property associated with the rescheduled  recurrence 
instance.

   B. 	Whether or not a unique ID is needed to tell local alarms from 
non-local alarms (and whether this ID will be called ALARMID or SEQUENCE)

   C.	Whether the CAP version will be a numeric version as in iCalendar or 
a list of supported RFCs.

   D.	Consensus about whether stored queries should be retained as part of 
CAP or not (and if so clarity about how they work)

Not-so-critical

   A.	Whether CALSCALE should be a required property returned in response 
to a GET-CAPABILITY command or not
   B.	Consensus and clarity in the document about what is returned to a 
VQUERY with EXPAND=TRUE for a recurrence set: the occurrences within the 
date range of the query, or an attempt to return all the ocurrences.

OK - that's my list. If we can all post a short list of items, and merge 
them together, the scope of what needs to be done will be defined, and we 
can help get this finished.

Tim Hare

---

From: Tim Hare <[email-masked]>
Date: Thu, 20 Nov 2003 22:22:57 -0500

This may have been thought of before, but what if we defined a _small_ set 
of commands for the most frequently used queries, documented how they would 
work in the protocol, and required them to be supported?

My proposals:

GET-TODAY: returns all VEVENTS, VTODOS, VJOURNAL entries for the current 
date, expands anything which recurs within the current day; i.e. a 
"snapshot" of the current days VCALENDAR entries.

GET-NEXT: returns next VEVENT whose beginning is after the current 
date/time (or, alternatively, a date/time can be passed and the next VEVENT 
after that will be returned). If a current date/time is within a VEVENT's 
DTSTART/DTEND range, how would we return that.

PUT-VJOURNAL: create a VJOURNAL event for the current date/time with the 
text passed.

There may of course be others, these three are those I would use myself off 
the top of my head.

I believe this solves the problem for small-footprint CUAs, with little 
memory, (if such devices still exist by the time we get CAP out <grin>) 
better than the stored queries method.  The CUA only needs to send the 
command - the variables, which in most cases are date or date/time values, 
are implicitly defined from the clock of the responding CUA/CS.  This also 
eliminates the issues of network traffic since the CUA doesn't have to send 
a command to find the query, retrieve that query, modify it, and then send 
it as a series of commands.  The CUA just has to send one of the commands, 
and the desired results are returned.

If this proposal is accepted, my belief is that we should concurrently drop 
the idea of stored queries as it now exists.

Tim Hare

---

From: Tim Hare <[email-masked]>
Date: Thu, 20 Nov 2003 22:28:08 -0500

In RCF2445 under "4.6.3 Journal Component" it states:

 >Description: A "VJOURNAL" calendar component is a grouping of
 >   component properties that represent one or more descriptive text
 >   notes associated with a particular calendar date. The "DTSTART"
 >   property is used to specify the calendar date that the journal entry
 >   is associated with

Yet, DTSTART is not a _required_ property of a VJOURNAL entry. This seems 
to me to be an error in RFC2445 - can someone give me a use case or other 
reason for an undated VJOURNAL entry?

Thanks
Tim Hare

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Nov 2003 12:32:10 -0700

Tim Hare wrote:

> Critical:
>   A.    Consensus that the original author's interpretation of 
> recurrence-ID handling (quoted here) is or is not what should happen. 

This is an iTIP (or iCAL) issue, not a CAP issue. Although it will 
effect the code in
an implementation it will not effect the CAP protocol.

It needs to be moved from the CAP issue list to the iTIP-next (or 
iCAL-next) issue list.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Nov 2003 12:38:35 -0700

RFC2446 specifies that DTSTART is required in PUBLISH and ADD.
It is not needed in CANCEL. And those are the only three supported
METHOD's.

'dtstart' is not listed as required in the 2445 ABNF because it is not
always needed (METHOD:CANCEL).

Tim Hare wrote:

> Yet, DTSTART is not a _required_ property of a VJOURNAL entry. This 
> seems to me to be an error in RFC2445 - can someone give me a use case 
> or other reason for an undated VJOURNAL entry?
>
> Thanks
> Tim Hare

--

---

From: Tim Hare <[email-masked]>
Date: Fri, 21 Nov 2003 14:37:37 -0500

Agreed - I lost track of which discussion thread it was in.

At 12:32 PM 11/21/03 -0700, you wrote:

>This is an iTIP (or iCAL) issue, not a CAP issue. Although it will effect 
>the code in

---

From: Libby Miller <[email-masked]>
Date: Fri, 21 Nov 2003 23:54:36 +0000 (GMT)

(cross-posted for info - please don't reply to both lists, thanks)

> >http://www.w3.org/2002/12/cal/

Thanks for having a look at these Doug.

>  Extra CR LF's in them between components.

Sorry, could you clarify? the ics files in that directory are all
generated from tools which export iCalendar.

>  Some have no METHOD property - does that mean they are booked

I'll have to look into that.

>  Some VEVENTs have no SUBJECT or DESCRIPTION.

Descriptions and summaries are optional, as I understand it - is that
incorrect?

>   I noticed that the RDF format drops the 'VALUE' parameter completely.

VALUE (as in VALUE=BINARY, VALUE=DATE) is handled in various ways within
the RDF model.
So in RDF whether something is text or a uri is a crucial distinction
handled by the RDF syntax. Whether something is a DATE or a DATETIME is
handled using different RDF properties.

I think the main thing is that we can roundtrip between the RDF and
iCalendar versions, so we aren't losing information - inevitably there
will be differences in the syntactic representation that are difficult
to explain as we are translating between two different representational
languages.

>   The RDF-cal has a 'class' tag, that is not the same as the iCAL

hm, it's not intended to be different. All we have done is create uris
to represent the possible values for class, i.e. public, private,
confidential become

<class rdf:resource='http://www.w3.org/2002/12/cal/ical#private'/>

etc

this just fits in better with the way RDF works - it's much better at
matching URIs than strings.

>   The RDF-cal does not distinguish between property values and parameters.

this distinction doesn't really matter to RDF :)
We don't think that matters as long as we can get back to the iCalendar
format as required.

>   Is the XML tag replicated or is the value just put in 'as is'?

Which properties were you thinking of? If there were (say) two
descriptions then you would just repeat the tag. I don't think we have
come across any iCalendar data with repeated tags yet. RDF has an
underlying model of object->property->object, so the syntax would
depend on whether the repeated tag translated into an RDF object or
property.

>     a subject of 'subscribe xcal-dev'.

thanks, will do.
>     Archives at:            http://inet-consulting.com/xcal-dev

Thanks again for taking a look at what we've been doing - it's very
useful to get such detailed feedback from the iCalendar community.

Libby

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Nov 2003 17:45:09 -0700

>generated from tools which export iCalendar.

Nothing serious, but several of the components end with:

    CR LF CR LF

and not just

     CR LF

I do not know of a parser that can not handle it, but it is not per the 
2445 ABNF.

>Descriptions and summaries are optional, as I understand it - is that
Yes incorrect. When they have the METHOD property for example.  See the 
restriction
tables in RFC-2447. For example SUMMARY in a VEVENT PUBLISH is not
optional, but may be empty.

>to explain as we are translating between two different representational
How do you handle VALUE=x-user-type ?

Example:

    iCAL:

        x-foo-property;VALUE=x-user-type:1234

    RDF:

          ?

>matching URIs than strings.
Okay, perhaps because it looked different from the way the other 
property values
were translated I may have missed it. Looking closer...

As it appears that the URL specified is specific to iCAL, why is CLASS 
treated
as a special property type?

>We don't think that matters as long as we can get back to the iCalendar
Maybe ... still thinking about this.

>depend on whether the repeated tag translated into an RDF object or

Multi valued means two or more values for ONE property, not the same
property repeated twice. CATAGORIES for example allows one or more
values separated by a comma.

This example is one property with two valules:

    CATEGORIES:BUSINESS,HUMAN RESOURCES

>useful to get such detailed feedback from the iCalendar community.

And again I think that any WebDAV work should be separate from a 
specification
on translation of date from iCAL from and to XML.

--

---

From: Doug Royer <[email-masked]>
Date: Sun, 23 Nov 2003 18:19:36 -0700

Tim Hare wrote:

>
>   B.     Whether or not a unique ID is needed to tell local alarms 
> from non-local alarms (and whether this ID will be called ALARMID or 
> SEQUENCE) 

The issues is not local/non-local. The issue is the ability to uniquely 
identify VALARMS
within a component. And if VALARM will be the only component without a 
unique id.

--

---

From: John Stracke <[email-masked]>
Date: Mon, 24 Nov 2003 09:24:30 -0500

>We don't think that matters as long as we can get back to the iCalendar
That's incorrect.  You need to build an isomorphism between iCalendar 
and RDF, *not* between "iCalendar with the properties and parameters 
defined in RFC-2445" and RDF.

You're not the first to make this mistake; the xCal spec had the same 
problem (maybe it still does; not sure).  It's an easy mistake to make, 
since RFC-2445 comingles the data model with the low-level syntax.  But 
the guideline you need to adopt is that your definition of the mapping 
MUST NOT know anything about individual components, properties, or 
parameters; it MUST be able to handle any legal iCalendar object, even 
if it uses entities which aren't defined today.  Suppose two people have 
iCalendar-based CUAs, but there's an RDF store somewhere along the path 
between them; when an iCalendar object reaches that RDF store, and later 
gets extracted, the resulting iCalendar must be equivalent to the original.

Perhaps 2445bis should be split into two documents, one to define the 
syntax and one to define the data model (as was done with vCard; see 
RFC-242[56]).

-- 
/=====================================================\
|John Stracke      [email-masked]              |
|Principal Engineer|http://www.centive.com            |
|Centive           |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/

---

From: Arnaud Quillaud <[email-masked]>
Date: Mon, 24 Nov 2003 10:08:11 -0800

Was the freebusy model (responsabilities of the CS/CUA) totally clarified ?
I think it would deserve a few examples.

Arnaud Quillaud

> -----Original Message-----
> From: Tim Hare [mailto:[email-masked]]
> Sent: Thursday, November 20, 2003 7:04 PM
> To: [email-masked]
> Subject: list of items
> 
> 
> 
> recurrence-ID

---

From: Harrie Hazewinkel <[email-masked]>
Date: Tue, 25 Nov 2003 15:03:36 +0100

On Friday, November 21, 2003, at 04:22 AM, Tim Hare wrote:

>
> This may have been thought of before, but what if we defined a _small_ 
> set of commands for the most frequently used queries, documented how 
> they would work in the protocol, and required them to be supported?
>
> My proposals:
>
> GET-TODAY: returns all VEVENTS, VTODOS, VJOURNAL entries for the 
> current date, expands anything which recurs within the current day; 
> i.e. a "snapshot" of the current days VCALENDAR entries.
>
> date/time (or, alternatively, a date/time can be passed and the next 
> VEVENT after that will be returned). If a current date/time is within 
> a VEVENT's DTSTART/DTEND range, how would we return that.

Two things came to mind here.
1) The above 2 commands look like 'SNMP'.

2) I do not see a real advantage for both client and server.
    A) For a client you have to specify the current date and timezone.
       The timezone is needed to tell the server what dat he means in 
particular
       and must adjust it to the clients timezone. The server maybe in a 
different
       timezone.
    B) The server must translate this somehow into a query for a specific
       start and stop time. As a result, I believe the request is little
       easier on the client, but now more burden on a server.

Or am I missing something??

>
> PUT-VJOURNAL: create a VJOURNAL event for the current date/time with 
> the text passed.

Can you elaborate?? Since I believe this is close to a CREATE and then
there is no benefit.

>
> There may of course be others, these three are those I would use 
> myself off the top of my head.

In general, I think it could be interesting to look at which
common request are mainly made, but I believe more strongly that
having 'generic' commands can serve a better purpose.

> I believe this solves the problem for small-footprint CUAs, with 
> little memory, (if such devices still exist by the time we get CAP out 
> <grin>) better than the stored queries method.  The CUA only needs to 
> send the command - the variables, which in most cases are date or 
> date/time values, are implicitly defined from the clock of the 
> responding CUA/CS.  This also eliminates the issues of network traffic 
> since the CUA doesn't have to send a command to find the query, 
> retrieve that query, modify it, and then send it as a series of 
> commands.  The CUA just has to send one of the commands, and the 
> desired results are returned.

I would earlier believe that a mechanism to limit the amount of 
components
returned on a request woul help.

> If this proposal is accepted, my belief is that we should concurrently 
> drop the idea of stored queries as it now exists.

Why?? Just curious, not selecting a side.

regards,

Harrie

---

From: John Stracke <[email-masked]>
Date: Tue, 25 Nov 2003 09:13:53 -0500

>       easier on the client, but now more burden on a server.

Except that the server can be optimized for the standard queries, 
instead of having to parse incoming SQL from the client.

---

From: Tim Hare <[email-masked]>
Date: Wed, 26 Nov 2003 23:43:43 -0500

Not knowing SNMP that well, I'm not going to address your item 1) - I can't 
tell if it's a good or bad thing to look like SNMP.

As to 2) - the advantage to the client is the ability to have simple 
commands which are understood at the server, instead of building a 
complicated query or going through a complicated retrieval  and 
modification of a stored query, and in these two cases the client does not 
need to build DTSTART/DTEND information into a "query" since it's implicit 
in the definition of the command.

The timezone issue does need to be handled, however it's probably pretty 
easy: In my opinion if the client sends its current timezone along with the 
date on the GET-TODAY command (or the date/time of the GET-NEXT command), 
the server should return the responses translated to that timezone if 
necessary. If the client sends no timezone, the server should send whatever 
timezone is in the component. Also, if no date or date/time value is sent, 
the server should use its local clock to supply those values.

Also you are correct that my PUT-JOURNAL command is basically the same as 
CREATE with a VJOURNAL event, so PUT-JOURNAL is not necessary.

The reason I suggested dropping stored queries was because we never reached 
consensus, that I can tell, about how such items would be implemented; my 
suggestion was to provide some of the function that stored queries were 
supposed to provide in a simpler manner that would allow the CAP draft to 
be finished; stored queries can always be designed and included in a future 
revision to the protocol if people feel the work is worth it.

Limiting the amount of components on a request isn't necessarily good, 
because you might not get the components you want and then you'd have to 
have a way to generate a query which said "give me everything from *here* 
onward", send that, see if you got the right stuff, etcetera. This could be 
a network traffic and response time problem. The two alternatives I propose 
involve one request and one reply; the scope of the command limits the 
components _somewhat_  in the GET-TODAY command (how many components could 
there be for "today" in most use cases?) and to _one_ VEVENT in the 
GET-NEXT command. This would allow faster response and lower network load.

I have, as yet, been unable to think of other commands that would be as 
useful, or as commonly used. If anyone else has good ones to propose, I do 
believe that they should be the types of commands that are short and quick 
like to two above, with minimal  client modification required. The most 
basic use case I can think of is a device with programming in ROM whose 
function is to download today's information and display it - the entire 
function, in CAP, would be ROMable using the GET-TODAY command with no 
timezone and no date passed, yet it could still retrieve the up-to-date 
information.

Tim Hare

At 03:03 PM 11/25/03 +0100, you wrote:

>>set of commands for the most frequently used queries, documented how they 
>>would work in the protocol, and required them to be supported?
>>
>>My proposals:
>>
>>VEVENT after that will be returned). If a current date/time is within a 
>>VEVENT's DTSTART/DTEND range, how would we return that.
>
>>There may of course be others, these three are those I would use myself 
>>off the top of my head.
>
>>command - the variables, which in most cases are date or date/time 
>>values, are implicitly defined from the clock of the responding 
>>CUA/CS.  This also eliminates the issues of network traffic since the CUA 
>>doesn't have to send a command to find the query, retrieve that query, 
>>modify it, and then send it as a series of commands.  The CUA just has to 
>>send one of the commands, and the desired results are returned.
>
>I would earlier believe that a mechanism to limit the amount of components

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Nov 2003 13:20:58 -0700

Tim Hare wrote:

>
> The timezone issue does need to be handled, however it's probably 
> pretty easy: In my opinion if the client sends its current timezone 
> along with the date on the GET-TODAY command (or the date/time of the 
> GET-NEXT command), the server should return the responses translated 
> to that timezone if necessary. If the client sends no timezone, the 
> server should send whatever timezone is in the component. Also, if no 
> date or date/time value is sent, the server should use its local clock 
> to supply those values. 

The CUA timezone is passed down in the CUA capability reply. Lets just 
use that.

> The reason I suggested dropping stored queries was because we never 
> reached consensus, that I can tell, about how such items would be 
> implemented; my suggestion was to provide some of the function that 
> stored queries were supposed to provide in a simpler manner that would 
> allow the CAP draft to be finished; stored queries can always be 
> designed and included in a future revision to the protocol if people 
> feel the work is worth it. 

Part of the merging of ideas over the last few years (and note that 
stored queries have
been in CAP since it inception and in -00 of CAP). Included compromises. 
One of those
compromises was stored queries. As with any component the CS can have 
VCARs that
do no permit them to stored. But the conversations were to allow them exist.

> I have, as yet, been unable to think of other commands that would be 
> as useful, or as commonly used. If anyone else has good ones to 
> propose, I do believe that they should be the types of commands that 
> are short and quick like to two above, with minimal  client 
> modification required. The most basic use case I can think of is a 
> device with programming in ROM whose function is to download today's 
> information and display it - the entire function, in CAP, would be 
> ROMable using the GET-TODAY command with no timezone and no date 
> passed, yet it could still retrieve the up-to-date information. --

Predefining what they are is not the same issue as defining that
they can exist.

Some enterprise vendors do not want them because they are not
concerted with bandwidth. PDA and CELL vendors will do them anyway
because they (or their customer) has to pay $$$ for air time
if they do not exist. So the compromise was that we would
define how to store them. And again, a CS is free to VCAR
them to permission denied for a specific implementation
as one could do for any other component.

What user/vendor-A wants back may not be the same as what
user/vendor-B's cell phone is even capable of handling.
A might not be able to handle VJOURNAL - so why pay
for the bandwidth to transfer them.

They do not need to be predefined. Just a standard way for
them to be stored so that when vendor-C does a query all from
VAGENDA they will know what it is and if it can ignore them.

It is not as if a CS is going to allow all random CUAs
to deposit stored queries in any random calendar within
its store any more than the CS would allow a random CUA
to deposit booked entries in any random calendar.

We concluded during the original debates that trying
to predefine the exact query in advance was not going
to work as that depended on the target CUA and its target
customers. So we agreed that they could be stored and that
as VCAR's would limit them to the owner, they would be known
to the owners CUA(s), no mysterious object types to guess
at by non-same-vendor CUA's as they all would be the
same component type (VQUERY) . Ether the CUA knew what XXX
did or not. Ether you were allowed (by VCAR like any other
component) to modify it, remove it, add one, or not.