[Ietf-calsify] DTEND for day events

[reinhold at kainhofer.com (Reinhold Kainhofer)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 19 October 2005 16:42, Doug Fults wrote:
> Your description is very helpful.  When I first implemented iCalendar
> support awhile back, I was quite confused by why the actual calendars
> out there seemed to be doing something different than the spec in this
> regard.  

Well, apparently, all implementations got it wrong according to one author of 
rfc 2445 (see my mail a while back)... But since *all* do it consistently, 
let's now change the standard (or rather clear it up) to reflect reality ;-)

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDVmfoTqjEwhXvPN0RAhl9AJ9ZXxPZCk7sPTidw83DgrknGOQW0QCgxlLU
pRDWMvisEXksc2tg3XnVvqc=
=pOYV
-----END PGP SIGNATURE-----
From reinhold at kainhofer.com  Wed Oct 19 08:36:04 2005
From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Oct 19 08:36:27 2005
Subject: [Ietf-calsify] DTEND for day events
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 19 October 2005 16:29, [e-mail] wrote:
> I'm trying to close down this issue that was raised by Neal and answered by
> Jeffrey.  It does seem that 2445 has DTEND as always being exclusive, but
> it's not explained very well.  In an effort to clear up the confusion, we'd
> like to change 2445's text to include the following examples to clarify:
>
>    To specify a meeting that starts at 15:00 and ends at 16:00:
>
>    DTSTART:20051011T150000Z
>    DTEND:20051011T160000Z
>
>
>    To specify an event that will last all day on October 11th and October
>    12th:
>
>    DTSTART;VALUE=DATE:20051011
>    DTEND;VALUE=DATE:20051013
>
>    Note that DTEND is exclusive, as expressed in both examples.  The time
>    1600 is not included in the event duration of the first example and the
>    date of the 13th is not included in the duration of the second example.

Maybe we should also add an example where no DTEND is given. In particular, 
the DTEND is then effectively DTSTART+1 day (which section 4.6.1 explains as 
"end of the calendar date given by DTSTART").

So only 
    DTSTART;VALUE=DATE:20051011
without a DTEND is effectively equivalent to
    DTSTART;VALUE=DATE:20051011
    DTEND;VALUE=DATE:20051012


And how should the following be interpreted where DTSTART and DTEND are the 
same day? 
    DTSTART;VALUE=DATE:20051011
    DTEND;VALUE=DATE:20051011
I suppose this should then be a timeless event as opposed to an event that 
takes up the whole day.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDVmfnTqjEwhXvPN0RAi1kAJ4wsda5tECo3UPZLgSxC5sMd2le0wCfbDYK
/Z7npbvPRNdrWDO2ctbgGkk=
=Ggk1
-----END PGP SIGNATURE-----
From Internet-Drafts at ietf.org  Fri Oct 21 07:50:01 2005
From: Internet-Drafts at ietf.org ([e-mail])
Date: Fri Oct 21 07:50:05 2005
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-2446bis-00.txt 
Message-ID: <[e-mail]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Transport-Independent Interoperability Protocol (iTIP)
	Author(s)	: C. Daboo
	Filename	: draft-ietf-calsify-2446bis-00.txt
	Pages		: 122
	Date		: 2005-10-21
	
   This document specifies a protocol using the iCalendar object
   specification to provide scheduling interoperability between
   different calendar systems.  This is done in a general way so as to
   allow multiple methods of communication between systems.  Subsequent
   documents will define profiles of this protocol using specific
   interoperable methods of communications between systems.

   iTIP complements the iCalendar object specification by adding
   semantics for group scheduling methods commonly available in current
   calendar systems.  These scheduling methods permit two or more
   calendar systems to perform transactions such as publish, schedule,
   reschedule, respond to scheduling requests, negotiation of changes or
   cancel.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-calsify-2446bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-2446bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative
From aki.niemi at nokia.com  Fri Oct 21 09:20:48 2005
From: aki.niemi at nokia.com (Aki Niemi)
Date: Fri Oct 21 09:20:56 2005
Subject: [Ietf-calsify] xCal - time to submit?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

Speaking as calsify chair, I'd simply like to point out that this would 
in any case be strictly an individual effort; XML representation of 
iCalendar is firmly out of the scope of the calsify WG.

Cheers,
Aki

ext Doug Royer wrote:
> 
> 
> xCal has been around for quite a while. I have included
> the last comments (and they were great feedback).
> 
> Is it time to move xCal from draft to RFC status?
> This is the 2nd round of xCal. The first was was delayed so
> this version re-started at -00 as the other draft-many
> had expired.
> 
> Please let me know if you have any more issues:
> 
> http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-02.txt
> 
> If not, lets move this to RFC proposed standard.
> 
> Thanks!
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
From Doug at Royer.com  Fri Oct 21 12:04:38 2005
From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 21 12:04:50 2005
Subject: [Ietf-calsify] xCal - time to submit?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>


I may have forgot to set the REPLY-TO the xCal mailing list.
Often others overrode or ignored that.

And we have to post announcements to all related lists, else we are
told to when we ask for final last call.


Aki Niemi wrote:
> Speaking as calsify chair, I'd simply like to point out that this would 
> in any case be strictly an individual effort; XML representation of 
> iCalendar is firmly out of the scope of the calsify WG.
> 
> Cheers,
> Aki
> 

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051021/e9a9acd8/smime.bin
From aki.niemi at nokia.com  Sat Oct 22 09:13:45 2005
From: aki.niemi at nokia.com (Aki Niemi)
Date: Sat Oct 22 09:14:06 2005
Subject: [Ietf-calsify] xCal - time to submit?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

Nevertheless, your original message had calsify WG in the To header field.

My reply was simply a reminder, that that particular IETF WG (being the 
only active IETF WG addressed) is not responsible for this work, and 
that any submission of xCal to the IESG is by an *individual* and not 
endorsed by the working group. That's all.

Cheers,
Aki

ext Doug Royer wrote:
> 
> I may have forgot to set the REPLY-TO the xCal mailing list.
> Often others overrode or ignored that.
> 
> And we have to post announcements to all related lists, else we are
> told to when we ask for final last call.
> 
> 
> Aki Niemi wrote:
> 
>> Speaking as calsify chair, I'd simply like to point out that this 
>> would in any case be strictly an individual effort; XML representation 
>> of iCalendar is firmly out of the scope of the calsify WG.
>>
>> Cheers,
>> Aki
>>
> 
From aki.niemi at nokia.com  Sat Oct 22 12:15:11 2005
From: aki.niemi at nokia.com (Aki Niemi)
Date: Sat Oct 22 12:15:51 2005
Subject: [Ietf-calsify] Agenda requests for IETF64
Message-ID: <[e-mail]>

All,

We are scheduled to meet in Vancouver on Monday, Nov 7 for one hour. We 
will be composing the agenda for the meeting, and would now like to 
solicit agenda proposals from the group.

Naturally, the charter items will be considered priority items, but in 
all probability, we will have some time to discuss non-WG items, and/or 
dedicate some time to discuss specific topics of interest to this group.

Email your proposals privately to both chairs, please.

Cheers,
Aki
From aki.niemi at nokia.com  Sat Oct 22 12:44:38 2005
From: aki.niemi at nokia.com (Aki Niemi)
Date: Sat Oct 22 12:44:46 2005
Subject: [Ietf-calsify] xCal - time to submit?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

[Speaking as an individual, not chair.]

Hi,

A couple of issues occured to me while reading the draft:

First, the problem this draft is trying to solve seems approximately the 
same that MMUSIC aimed at in its SDPng work, in which the idea was to 
move from the current SDP into an XML based format. Even the core 
difficulty seems to be the same, namely the huge installed base only 
supporting the legacy format makes transition a bit hairy.

Secondly, if we think of xCal as being a next generation iCal format, 
wouldn't it be more beneficial to design it from scratch instead of 
simply doing a 1:1 syntactic transform? After all, XML offers a lot of 
additional features that could be leveraged when doing a "better" 
calendar format.

A very simple example: rather than using "x-" prefix for private 
extensions, standard XML techniques could be used, i.e., putting the 
private extension element under a private (different) XML namespace.

This really boils down to "why?". What benefit is there to define this 
iCal to XML transformation? Because XML is cool is not enough, IMO, 
there needs to be some real benefits as well, especially when there is 
this huge existing installed base for iCal.

Having said all this, this might still be interesting work for even the 
IETF to take on, but I strongly feel this work would benefit from a much 
wider audience. Perhaps in the form of some comments and experiences 
from the MMUSIC WG, and probably a few thoughts from the XML "mafia" of 
the IETF as well.

Personally, I think this ought to be aiming at a BoF rather than an 
individual submission to the IESG.

Cheers,
Aki

ext Doug Royer wrote:
> 
> 
> xCal has been around for quite a while. I have included
> the last comments (and they were great feedback).
> 
> Is it time to move xCal from draft to RFC status?
> This is the 2nd round of xCal. The first was was delayed so
> this version re-started at -00 as the other draft-many
> had expired.
> 
> Please let me know if you have any more issues:
> 
> http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-02.txt
> 
> If not, lets move this to RFC proposed standard.
> 
> Thanks!
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
From Doug at Royer.com  Sat Oct 22 13:15:39 2005
From: Doug at Royer.com (Doug Royer)
Date: Sat Oct 22 13:15:44 2005
Subject: [Ietf-calsify] xCal - time to submit?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>



Aki Niemi wrote:
> [Speaking as an individual, not chair.]
> 
> Hi,
> 
> A couple of issues occured to me while reading the draft:
> 
> First, the problem this draft is trying to solve seems approximately the 
> same that MMUSIC aimed at in its SDPng work, in which the idea was to 
> move from the current SDP into an XML based format. Even the core 
> difficulty seems to be the same, namely the huge installed base only 
> supporting the legacy format makes transition a bit hairy.

What move?

What transition?

> Secondly, if we think of xCal as being a next generation iCal format, 

Clearly you have not read the draft. It says:


  	This memo only provides an alternative, XML
    	representation for the standard syntax defined in [iCAL].

No 'Next generation' at all.

If you go to the CALSCH mailing list archives you can see that other
non-1:1 mappings of iCal were NOT desired and discouraged by the IESG.


> wouldn't it be more beneficial to design it from scratch instead of 
> simply doing a 1:1 syntactic transform?

Fell free to submit such a draft. The xCal draft allow iCal
data "as defined in iCal to be mixed with XML data.

The rest of your email seems to repeat your above point.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051022/fc2af820/smime.bin
From aki.niemi at nokia.com  Sun Oct 23 05:28:11 2005
From: aki.niemi at nokia.com (Aki Niemi)
Date: Sun Oct 23 05:28:47 2005
Subject: [Ietf-calsify] xCal - time to submit?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

[Speaking as individual again]

Inline.

ext Doug Royer wrote:
> 
> 
> Aki Niemi wrote:
> 
>> [Speaking as an individual, not chair.]
>>
>> Hi,
>>
>> A couple of issues occured to me while reading the draft:
>>
>> First, the problem this draft is trying to solve seems approximately 
>> the same that MMUSIC aimed at in its SDPng work, in which the idea was 
>> to move from the current SDP into an XML based format. Even the core 
>> difficulty seems to be the same, namely the huge installed base only 
>> supporting the legacy format makes transition a bit hairy. 
> 
> What move?

As in stop using the current format and start using the new one.

> What transition?

As in how to cope with the co-existance of applications that support the 
  new format and the old format, and applications that only support the 
old format.

I thought you were familiar with these issues since the draft talks 
about them as well.

In the draft you suggest using multipart/alternative as a transitional 
mechanism. I find that solution lacking, in that will there ever be a 
time when apps can stop using MIME multipart, and simply use the xCal 
MIME type alone? Is that even the intention? If not, what is the benefit 
in defining this alternative format, if the only practical result is 
bloated message payload?

Your draft also says:

    XML
    applications conforming to this specification MUST be able to
    properly parse and process a MIME multipart entity containing the
    MIME type associated with this iCalendar XML document type.

Which is nice, but does not help at all. It is the legacy iCalendar 
application that would need to support MIME multiparts, in order for 
this "transition" to work. A big number does, but probably not all; how 
is this handled?

>> Secondly, if we think of xCal as being a next generation iCal format, 
> 
> Clearly you have not read the draft. It says:

I consider this type of statement quite a weak form of argument in 
general. If something does not come across well in a draft, often the 
reader is not at fault, but the draft needs improvement.

Believe me, I read the draft. I would not be shooting my mouth off if I 
hadn't. :)

>      This memo only provides an alternative, XML
>        representation for the standard syntax defined in [iCAL].
> 
> No 'Next generation' at all.

Why is this then needed at all? As I said in my previous post, because 
XML is cool is not a good enough reason. If it was, then I'm sure the 
ASN.1 constituent would deserve a format as well, followed by a league 
of other groups that like their data representation scheme the best.

Your draft doesn't explain this point, and I think it really should.

> If you go to the CALSCH mailing list archives you can see that other
> non-1:1 mappings of iCal were NOT desired and discouraged by the IESG.

I see, was a reason given? Should this discussion appear in the draft? 
It would really help those of us who have not followed calsch in the 
past in detail

Cheers,
Aki
From dave at cridland.net  Sun Oct 23 06:57:39 2005
From: dave at cridland.net (Dave Cridland)
Date: Sun Oct 23 06:57:46 2005
Subject: [Ietf-calsify] xCal - time to submit?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
	<[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>

On Sun Oct 23 13:28:11 2005, Aki Niemi wrote:
> ext Doug Royer wrote:
>> What move?
> 
> As in stop using the current format and start using the new one.
> 
>> What transition?
> 
> As in how to cope with the co-existance of applications that 
> support the  new format and the old format, and applications that 
> only support the old format.

I think the problem with xCal is not that it's an irrelevant and 
pointless format, because it isn't - I think it's potentially very 
useful. But it's nothing to do with this WG, which is why reaction is 
pretty hostile. Here, the WG is trying to get decent interoperability 
between calendaring applications. XML doesn't help that in the 
slightest, and as you point out, if anything, it hurts that.

However, many existing systems work "better" with XML, and so I can 
fully understand that a neat method of producing iCal objects in XML 
is valuable. No, I don't want to see iMIP capable CUAs start to send 
out xCal, as that'd be pointless, but yes, a web-based calendaring 
system might well be capable of spitting out xCal if requested, and 
some simple front-ends may even require that - and that's fine.

So essentially, I think xCal as a concept is fine, just that care 
should be taken to define its scope a little better.

I *haven't* read the draft, incidentally, but I still can tell the 
scope is obviously not clearly defined, because otherwise the threads 
going on in this WG about xCal would presumably be very different.

If xCal is actually presented as "a better format", then it's 
over-egging itself (I think a child of four could make a better 
format than iCal, but the deployed base renders this a waste of 
time). If xCal presents itself as a format more suited to XML-centric 
environments, than I'm all for it.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw
From Doug at Royer.com  Sun Oct 23 07:36:41 2005
From: Doug at Royer.com (Doug Royer)
Date: Sun Oct 23 07:37:03 2005
Subject: [Ietf-calsify] xCal - time to submit?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>



Aki Niemi wrote:
> [Speaking as individual again]
> 
> Inline.
> 
> ext Doug Royer wrote:
> 
>>
>>
>> Aki Niemi wrote:
>>
>>> [Speaking as an individual, not chair.]
>>>
>>> Hi,
>>>
>>> A couple of issues occured to me while reading the draft:
>>>
>>> First, the problem this draft is trying to solve seems approximately 
>>> the same that MMUSIC aimed at in its SDPng work, in which the idea 
>>> was to move from the current SDP into an XML based format. Even the 
>>> core difficulty seems to be the same, namely the huge installed base 
>>> only supporting the legacy format makes transition a bit hairy. 
>>
>>
>> What move?
> 
> 
> As in stop using the current format and start using the new one.

What new one? xCal is YEARS old.

Its clear that you have not really read xCal. And it is clear
that you are not interested in discussing any real points in the draft.


-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051023/7398b497/smime-0001.bin
From Internet-Drafts at ietf.org  Wed Oct 26 15:50:02 2005
From: Internet-Drafts at ietf.org ([e-mail])
Date: Wed Oct 26 15:50:05 2005
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-00.txt 
Message-ID: <[e-mail]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux, C. Stoner
	Filename	: draft-ietf-calsify-rfc2445bis-00.txt
	Pages		: 166
	Date		: 2005-10-26
	
   Calendar systems export, transport and sometimes even store calendar
   information in a standard, interoperable format.  This memo defines
   the common format for openly exchanging calendaring and scheduling
   information across the Internet, known as the iCalendar object
   format.  An iCalendar object may represent an event, to-do or task,
   or journal entry (note).

   Comments are solicited and should be addressed to the working group's
   mailing list at [e-mail] and/or the editor.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-calsify-rfc2445bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative
From bernard.desruisseaux at oracle.com  Fri Oct 28 07:30:34 2005
From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Fri Oct 28 07:30:47 2005
Subject: [Ietf-calsify] How to derive FREEBUSY;FBTYPE from a VEVENT?
Message-ID: <[e-mail]>

The FBTYPE parameter of FREEBUSY properties of VFREEBUSY components
can take one of the following values:

  - FREE
  - BUSY
  - BUSY-UNAVAILABLE
  - BUSY-TENTATIVE
  - x-name

How can a calendar application (e.g., CalDAV Server) derive the
proper FBTYPE value from a given VEVENT?

Assuming that the FBTYPE parameter of the FREEBUSY property of
a VFREEBUSY component should be derived from the TRANSP and
STATUS properties of the VEVENT component, does the following
table make sense?

     +---------------------------++------------------+
     |          VEVENT           || VFREEBUSY        |
     +-------------+-------------++------------------+
     | TRANSP      | STATUS      || FBTYPE           |
     +=============+=============++==================+
     | TRANSPARENT | <Any value> || FREE             |
     +-------------+-------------++------------------+
     |             | CANCELLED   || FREE             |
     |             +-------------++------------------+
     |             | <Undefined> || BUSY             |
     | OPAQUE      | CONFIRMED   ||                  |
     | <Undefined> +-------------++------------------+
     |             |    ???      || BUSY-UNAVAILABLE |
     |             +-------------++------------------+
     |             | TENTATIVE   || BUSY-TENTATIVE   |
     +-------------+-------------++------------------+

When would a calendar application derive FBTYPE=BUSY-UNAVAILABLE ?

When would a calendar application derive FBTYPE=x-name ?

Cheers,
Bernard