Editors notes 8-MAY-02

(long)

You will not see these changes below until we push a new version
of the draft. If the chairs are okay with it, I can publish
on a web site the interm-working-version?

I spent some more time working on and catching up to all
of the WG comments that have not been acted upon. I added 
several things - many edits. Some were implied on the WG list,
others were explicit:

Mandated that the CAPABILITIES reply always be in UTF-8.

  This allows CUA's to determine the LOCALE's and CHARSET's

  the CS supports. Without this requirement, there is NO
  way to determine which charset and locale the CAPABILITIES
  the CS is running at the moment (Thus making the command
  unreadable to the CS and the reply unreadable to the CUA).
  This was not explicitly discussed. But there have been NO
  proposals as this seemed as good as any.

Mandated that upon initial connection, the CS be using the
UTF-8 charset.

   There needed to be a MUST charset specified and a
   starting point to switch (see below).

Added a requirement that the CUA AND CS can only send

Re: Editors notes 8-MAY-02

>You will not see these changes below until we push a new version
>of the draft. If the chairs are okay with it, I can publish
>on a web site the interm-working-version?

If you've got the interim version, wouldn't it be just as easy to submit 
it as an I-D? It'd be good for anybody looking in the I-D repository to 
see the latest version.

>Mandated that the CAPABILITIES reply always be in UTF-8.

Makes sense to me.

>I changed 'user <at> *' to say 'Not recommended". I would like
>to say "not valid". Per the list discussion.

I think you're right; it should be invalid--it's just as weak as 
anonymous.

>I edited the change control to say 'submit draft for RFC approval...'
>There has been no justification for a 'method reviewer' and
>there has been much debate about how to structure it. So I changed
>it to what every other RFC does - tell them to generate an RFC.

I like it (not that I think that will surprise anybody .

/========================================================\
|John Stracke                    |Principal Engineer     |
|jstracke <at> incentivesystems.com   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|

Adding CAP extensions to xCal

Is there any plan underway that will add the CAP extensions to iCalendar in
xCal?  The reason I'm asking is I'm doing research for using Jabber as a
transport layer for Calendaring.

Thanks.

Jim Ray

Re: Adding CAP extensions to xCal

>Is there any plan underway that will add the CAP extensions to iCalendar 
in
>xCal?

The XML representation of iCalendar will have to be an isomorphism.  This 
means that, once it's defined, it will automatically inherit any 
extensions.

/================================================================\
|John Stracke                    |Principal Engineer             |
|jstracke <at> incentivesystems.com   |Incentive Systems, Inc.        |
|http://www.incentivesystems.com |My opinions are my own.        |
|================================================================|
|The voices say I'm not schizophrenic, but they're not sure about|
|you.                                                            |
\================================================================/

Re: Adding CAP extensions to xCal

Jim,

Feel free to send me some email with some details on what you are 
looking for. This mailing list is focusing on getting CAP out. Once that 
happens, xCal and other things will be more active.

Gary

Jim Ray wrote:
> Is there any plan underway that will add the CAP extensions to iCalendar in
> xCal?  The reason I'm asking is I'm doing research for using Jabber as a
> transport layer for Calendaring.
> 
> Thanks.
> 
> Jim Ray

Re: Adding CAP extensions to xCal

Jim Ray wrote:
> 
> Is there any plan underway that will add the CAP extensions to iCalendar in
> xCal?  The reason I'm asking is I'm doing research for using Jabber as a
> transport layer for Calendaring.

The CAP commands will always be in CAP format.
It is possible that a draft will be written that will allow
xCal to optionally be transported in CAP.

-Doug

Re: Yokahama

At 7:08 PM -0400 4/25/02, pregen <at> egenconsulting.com wrote:
>We are trying to determine how many people will be in Yokahama. If 
>you are planning on attending this meeting, please post to the list.

Folks-

We've yet to see any indication that anyone from this WG will be 
present in Yokahama.  If there are folks intending to go, it would be 
appreciated if you could raise your hands.

We have not yet requested a meeting slot...  If we want to meet, we 
need to make our intentions known.

("Maybe" is an acceptable response in this instance)

Thanks.

-Bob

Obtaining a users freebusy data.

I have been reading the CAP spec (ver 7)  and attempting to create some 
example cases
that could be used to add the use of a CAP server to a client.
I have become stuck with the problem of obtaining FREEBUSY data. I can
see several ways of resolving the problem, but am unsure which to follow.

The case is: Get todays freebusy data from calendar markcal1, where today
is 17th May 2002 in London.

1) You could create an iTip freebusy request containing a VFREEBUSY
REQUEST, and expect the server to give you an iTip reply containing a 
VFREEBUSY
object with FREEBUSY properties.

2) You could search for VFREEBUSY components that have DTSTART and DTEND
properties in the correct range.

3) You could search for VEVENT and VTODO components with DTSTART and DTEND
properties in the correct range, that are booked and not transparent.

Is the server expecting the client to store VFREEBUSY data, or is it 
calculating it
from the event data it already knows?

Thanks
 Mark Davidson

Re: Obtaining a users freebusy data.

>1) You could create an iTip freebusy request containing a VFREEBUSY
>REQUEST, and expect the server to give you an iTip reply containing a 
>VFREEBUSY
>object with FREEBUSY properties.

I think this is the correct approach, because it's the one that's likely 
to work with minimal privileges--I'm more likely to let you submit an iTIP 
request than to let you actually search my calendar.  It's also a good 
idea because you can reuse the code for anybody you can reach via 
iTIP--say, if you don't know my cap: address, but you do have my email 
address, you can send me an iMIP message.

/=================================================================\
|John Stracke                    |Principal Engineer              |
|jstracke <at> incentivesystems.com   |Incentive Systems, Inc.         |
|http://www.incentivesystems.com |My opinions are my own.         |
|=================================================================|
|Two words that inspire the same feeling of dread are synominous. |
\=================================================================/

Yokahama meeting