headers
Internet-Drafts | 1 Feb 2010 18:00
Picon
Favicon

[ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-08.txt

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 Message-Based Interoperability Protocol (iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-08.txt
	Pages		: 22
	Date		: 2010-1-30
	
This document, iCalendar Message-Based Interoperability Protocol
   (iMIP), specifies a binding from the iCalendar Transport-independent
   Interoperability Protocol (iTIP) to Internet email-based transports.
   Calendaring entries defined by the iCalendar Object Model (iCalendar)
   are wrapped using constructs from RFC 5322, RFC 2045, RFC 2046, RFC
   2047 and RFC 2049, and then transported over SMTP.

   This document is a product of the Calendaring and Scheduling
   Standards Simplification (calsify) working group. More information
   about the IETF CALSIFY working group activities can be found on the
   IETF web site at <http://www.ietf.org/html.charters/calsify-
   charter.html>.

   The issue tracker for the Calsify WG is located at:
    <http://www.ofcourseimright.com/cgi-bin/roundup/calsify>

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

Internet-Drafts are also available by anonymous FTP at:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Desruisseaux | 10 Feb 2010 21:48
Picon
Favicon

Re: [ietf-calsify] [Technical Errata Reported] RFC5545 (2039)

ADs should approve this errata.

Thanks,
Bernard

RFC Errata System wrote:
> The following errata report has been submitted for RFC5545,
> "Internet Calendaring and Scheduling Core Object Specification (iCalendar)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=2039
>
> --------------------------------------
> Type: Technical
> Reported by: Arnout Engelen <arnouten <at> bzzt.net>
>
> Section: 4
>
> Original Text
> -------------
>        BEGIN:VALARM
>        ACTION:AUDIO
>        TRIGGER:19980403T120000Z
>        ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
>         files/ssbanner.aud
>        REPEAT:4
>        DURATION:PT1H
>        END:VALARM
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Desruisseaux | 10 Feb 2010 21:48
Picon
Favicon

Re: [ietf-calsify] [Editorial Errata Reported] RFC5545 (2038)

ADs should approve this errata.

Thanks,
Bernard

RFC Errata System wrote:
> The following errata report has been submitted for RFC5545,
> "Internet Calendaring and Scheduling Core Object Specification (iCalendar)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=2038
>
> --------------------------------------
> Type: Editorial
> Reported by: Arnout Engelen <arnouten <at> bzzt.net>
>
> Section: Appendix A
>
> Original Text
> -------------
>    5.  The "DURATION" property can no longer appear in "VFREEBUSY"
>        components.
>
> A.2. Restrictions Removed
>
>
>
> Corrected Text
> --------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gren Elliot | 26 Feb 2010 15:06

VTIMEZONES with onset times in the future of appointments

Hi,

I'm starting to see ICAL appearing in the wild from a well known mobile phone provider's devices with VEVENT dates referencing a VTIMEZONE component whose rules' onset times are in the future of the actual appointment.  Any views on how these should be treated?  The libical library we use assumes (not unreasonably IMHO) that such times are UTC - which is clearly at odds with the actual intent.

For example, the following contains a VTIMEZONE with only 2 rules that first apply from 14th March (DST) or 17th Nov (Standard) this year, but the appointment is on 17th February this year...
... BEGIN:VTIMEZONE TZID:US/Central BEGIN:DAYLIGHT DTSTART:20100314T020000 RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3 TZNAME:CDT TZOFFSETFROM:-0600 TZOFFSETTO:-0500 END:DAYLIGHT BEGIN:STANDARD DTSTART:20101107T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11 TZNAME:CST TZOFFSETFROM:-0500 TZOFFSETTO:-0600 END:STANDARD END:VTIMEZONE BEGIN:VEVENT ... DTSTART;TZID=US/Central:20100217T170000 DTEND;TZID=US/Central:20100217T180000 ... Regards,
Gren.
-- Gren Elliot Senior Software Engineer *Scalix* gren.elliot <at> scalix.com Tel: +44 1344 381812 www.scalix.com 
_______________________________________________
calsify mailing list
calsify <at> ietf.org
https://www.ietf.org/mailman/listinfo/calsify
Permalink | Reply | 2 comments |
headers
Cyrus Daboo | 26 Feb 2010 16:05
Favicon

Re: VTIMEZONES with onset times in the future of appointments

Hi Gren,

--On February 26, 2010 2:06:33 PM +0000 Gren Elliot 
<gren.elliot <at> scalix.com> wrote:

> I'm starting to see ICAL appearing in the wild from a well known mobile
> phone provider's devices with VEVENT dates referencing a VTIMEZONE
> component whose rules' onset times are in the future of the actual
> appointment.  Any views on how these should be treated?  The libical
> library we use assumes (not unreasonably IMHO) that such times are UTC -
> which is clearly at odds with the actual intent.
>
> For example, the following contains a VTIMEZONE with only 2 rules that
> first apply from 14th March (DST) or 17th Nov (Standard) this year, but
> the appointment is on 17th February this year...

If the timezone id is "well known" you could simply map the client's 
timezone to one your server has stashed (and which is complete) and just 
substitute that. Our server does that - we use the Olson db and parse that 
on startup to cache timezone ids. Then whenever a new id is seen the 
calendar library loads the timezone definition from our cache rather than 
use the one in the data provided. Of course this is risky in that it 
assumes the same timezone id is really being used the same way by both 
client and server - but at this point I think we have to reasonably make 
that assumption.

One day we will have a standard timezone registry so there would be a 
guarantee that ids always represent the same set of timezone rules. This is 
a perfect example of why such a registry is needed!

--

-- 
Cyrus Daboo
Permalink | Reply | 0 comments |
headers
Gren Elliot | 26 Feb 2010 16:53

Re: VTIMEZONES with onset times in the future of appointments

On 26/02/2010 15:14, Rick DeNatale wrote:
> As I understand it, in the case of an event time prior to the event
> time with a timezone, you should use the UTC offset specified in the
> TZOFFSETFROM property of the earliest DAYLIGHT or STANDARD period of
> that time zone, which would be the DAYLIGHT period starting at
> 20100314T020000, so the offset would be -0600,
>
> Note that each DAYLIGHT/STANDARD period carries not only the offset to
> be applied during that period, but also the offset applied for the
> previous period.
>
> This allows for dealing with times before a given timezone existed, or
> more to the point before daylight savings time was introduced to a
> given timezone.
>    

Good point - I hadn't thought of that aspect.  In which case the problem 
isn't as bad as I had thought it was.
Cyrus's suggestion on using the system timezone definitions in 
preference also has a lot of merits.
I'll probably end up with fixes based on some mix of the 2 ideas (as not 
all TZIDs may be known on the system).

Thanks to you both,

Regards,
Gren.
Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 26 Feb 2010 21:07
Favicon

Individual submission: new iCalendar properties

Hi folks,
I have just uploaded a new draft that defines some new iCalendar properties 
(<http://tools.ietf.org/html/draft-daboo-icalendar-extensions>). Several of 
these are ones that have various X- variants floating around, so this draft 
is an attempt to standardise the name and usage as per our new IANA 
registry process.

Comments welcome.

--

-- 
Cyrus Daboo
Permalink | Reply | 1 comment |

Gmane