Reinhold Kainhofer | 13 Jan 14:52 2010

[ietf-calsify] Indicating a completed to-do???

Hi all,
Recently the issue came up in kde how a completed to-do is supposed to be 
indicated. There are three different completion settings defined in rfc 5545:
-) STATUS:COMPLETED (as opposed to NEEDS-ACTION)
-) COMPLETED:20070707T100000Z
-) PERCENT-COMPLETE:100

However, the RFC is quiet which of those is supposed to indicate that a to-do 
is actually completed... There is, however, an example in section 3.6.2 of a 
completed to-do:

      The following is an example of a "VTODO" calendar component that
      was due before 1:00 P.M. UTC on July 9th, 2007 and was completed
      on July 7th, 2007 at 10:00 A.M. UTC.

       BEGIN:VTODO
       UID:20070514T103211Z-123404 <at> example.com
       DTSTAMP:20070514T103211Z
       DTSTART:20070514T110000Z
       DUE:20070709T130000Z
       COMPLETED:20070707T100000Z
       SUMMARY:Submit Revised Internet-Draft
       PRIORITY:1
       STATUS:NEEDS-ACTION
       END:VTODO

Is the STATUS:NEEDS-ACTION really intended or is it an oversight and should 
rather be STATUS:COMPLETED???

The problem we have is interoperability: Horde creates a VTODO with
(Continue reading)

Calvin So | 13 Jan 19:01 2010
Picon

[ietf-calsify] Group Event

Hi folks, 

I am not sure if my case is feasible but I am trying to write a 
backend program that send out message to "A", "B", "C" and "D" and 
make "A" as the organizer/chair of a group event and the others as the 
attendees. 

I have read the "4.2. Group Event Examples" in 
http://ri-cal.rubyforge.org/rdoc/docs/draft-ietf-calsify-2446bis-08_t... 
but it doesn't mention much about what message content should be 
constructed for message sending to "A" 

Can somebody shed some light on this? In particular, which parameter 
(s) should I pay special attention to? Or there is no feasible 
solution for my case? 

Thanks! 

_______________________________________________
ietf-calsify mailing list
ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Cyrus Daboo | 13 Jan 19:34 2010

Re: [ietf-calsify] Group Event

Hi Calvin,

--On January 13, 2010 10:01:40 AM -0800 Calvin So <sochihong <at> gmail.com> 
wrote:

> I am not sure if my case is feasible but I am trying to write a 
> backend program that send out message to "A", "B", "C" and "D" and 
> make "A" as the organizer/chair of a group event and the others as the 
> attendees. 
>
> I have read the "4.2. Group Event Examples" in 
> http://ri-cal.rubyforge.org/rdoc/docs/draft-ietf-calsify-2446bis-08_t... 
> but it doesn't mention much about what message content should be 
> constructed for message sending to "A" 
>
> Can somebody shed some light on this? In particular, which parameter 
> (s) should I pay special attention to? Or there is no feasible 
> solution for my case? 

Strictly speaking in the iTIP model messages are assumed to be originated 
by the Organizer. In your case it looks like you want some third party to 
originate the message and make sure it also gets put on the Organizer's 
calendar. Does the third party have any direct access to the Organizer's 
calendar? Are you expecting the Attendee's to reply to the organizer with 
their participation status updates?

--

-- 
Cyrus Daboo

_______________________________________________
ietf-calsify mailing list
ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Reinhold Kainhofer | 13 Jan 22:08 2010

Re: [ietf-calsify] Group Event

Am Mittwoch, 13. Januar 2010 19:34:33 schrieb Cyrus Daboo:
> Hi Calvin,
> 
> --On January 13, 2010 10:01:40 AM -0800 Calvin So <sochihong <at> gmail.com>
> 
> wrote:
> > I am not sure if my case is feasible but I am trying to write a 
> > backend program that send out message to "A", "B", "C" and "D" and 
> > make "A" as the organizer/chair of a group event and the others as the 
> > attendees. 

Okay, so basically your programm (who is operating it???) is the organizer. 
There should be some human contact organizing (i.e. fixing the date, 
organizing the room, informing the participants about changes, etc.) the event 
with A,B,C and D. That human contact (email address) should be the ORGANIZER 
of the event.

The fact that A is the CHAIR of the meeting can be indicated by the ROLE 
parameter of the ATTENDEE:

       ATTENDEE;ROLE=CHAIR:mailto:mrbig <at> example.com

See section 3.2.16 of RFC 5545

All other attendees will either have no ROLE parameter (implicitly, REQ-
PARTICIPANT is assumed in that case) or an explicit ROLE parameter:

       ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry
        Cabot:mailto:hcabot <at> example.com

> > I have read the "4.2. Group Event Examples" in 
> > http://ri-cal.rubyforge.org/rdoc/docs/draft-ietf-calsify-2446bis-08_t... 
> > but it doesn't mention much about what message content should be 
> > constructed for message sending to "A" 

You should definitely also read RFC 5545 (the successor to RFC 2445) about 
ATTENDEE, ORGANIZER and all its parameters. RFC 2446bis builds on RFC5545.

> > Can somebody shed some light on this? In particular, which parameter 
> > (s) should I pay special attention to? Or there is no feasible 
> > solution for my case? 
> 
> Strictly speaking in the iTIP model messages are assumed to be originated
> by the Organizer. In your case it looks like you want some third party to
> originate the message and make sure it also gets put on the Organizer's
> calendar. 

You are using "organizer" for two different tasks: 1) really organizing the 
event and 2) chairing the event.

> Does the third party have any direct access to the Organizer's
> calendar? Are you expecting the Attendee's to reply to the organizer with
> their participation status updates?

Exactly, this is the issue. if your application simply acts on behalf of the 
chair/organizer (i.e. can fix dates for him/her, has access to the calendar, 
etc. like a secretary), the chair or the secretary should also be the 
ORGANIZER and will receive all replies by the attendees. 

Otherwise, the chair is simply a "normal" attendee with a special role at the 
meeting. In that case the ORGANIZER is someone else and the chair is an 
ATTENDEE with ROLE=CHAIR.

Cheers,
Reinhold

--

-- 
------------------------------------------------------------------
Reinhold Kainhofer, reinhold <at> kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
Doug Day | 14 Jan 16:29 2010

Re: [ietf-calsify] Indicating a completed to-do???

Reinhold,

Those are some good points, and I'd like to hear other's view on this.

My personal interpretation is that the STATUS is the driving field here;  both the COMPLETED and PERCENT-COMPLETE are there for informational purposes when determining if the VTODO is complete.

However, there is a kink with this philosophy:

1.  VTODO items can recur.
2.  The only solution I can see for tracking completed status is a combination of the STATUS property and the COMPLETED property.  If the STATUS field is set to COMPLETED, but the VTODO recurs, then the COMPLETED date should be used to determine when the event is again due?  This is a tricky situation -- one I'd like to see resolved.

For example.  Say you have a VTODO that looks like this:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VTODO
UID:fed50a1c-1e72-11db-a465-aae271be3660
SUMMARY:Test Todo
STATUS:COMPLETED
COMPLETED;TZID=US-Eastern:20060825T100000
CLASS:PRIVATE
DTSTART;TZID=US-Eastern:20060728T090000
RRULE:FREQ=WEEKLY;INTERVAL=3;UNTIL=20061207T160000Z
DTSTAMP:20060728T195437Z
END:VTODO
BEGIN:VTIMEZONE
TZID:US-Eastern
LAST-MODIFIED:19870101T000000Z
TZURL:http://zones.stds_r_us.net/tz/US-Eastern
BEGIN:STANDARD
DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
END:VCALENDAR

Notice the VTODO has been marked both in COMPLETED status and with a COMPLETED date/time.  However, the VTODO is also scheduled to recur every 3 weeks.  Should the status be reset to NEEDS-ACTION after this time?  Should that be implicit?  How should a CUA handle this situation?

Also, how should the recurrence rule be handled?  It seems it should be scheduled 3 weeks from the COMPLETED date/time.  Is that accurate?

Any thoughts?
-Doug Day
http://www.ddaysoftware.com

Reinhold Kainhofer wrote:
Hi all, Recently the issue came up in kde how a completed to-do is supposed to be indicated. There are three different completion settings defined in rfc 5545: -) STATUS:COMPLETED (as opposed to NEEDS-ACTION) -) COMPLETED:20070707T100000Z -) PERCENT-COMPLETE:100 However, the RFC is quiet which of those is supposed to indicate that a to-do is actually completed... There is, however, an example in section 3.6.2 of a completed to-do: The following is an example of a "VTODO" calendar component that was due before 1:00 P.M. UTC on July 9th, 2007 and was completed on July 7th, 2007 at 10:00 A.M. UTC. BEGIN:VTODO UID:20070514T103211Z-123404 <at> example.com DTSTAMP:20070514T103211Z DTSTART:20070514T110000Z DUE:20070709T130000Z COMPLETED:20070707T100000Z SUMMARY:Submit Revised Internet-Draft PRIORITY:1 STATUS:NEEDS-ACTION END:VTODO Is the STATUS:NEEDS-ACTION really intended or is it an oversight and should rather be STATUS:COMPLETED??? The problem we have is interoperability: Horde creates a VTODO with STATUS:COMPLETED COMPLETED:20100112T125449Z while Korganizer and kontact instead use only the completion percentage: COMPLETED:20100112T124208Z PERCENT-COMPLETE:100 Unfortunately, this totally breaks the exchange of to-dos between horde and kontact, as completed to-dos in one application won't be detected as completed in the other. In the RFC I couldn't find anything that says that one of the is "correct" and the other is not... Cheers, Reinhold
Reinhold
CONFIDENTIALITY NOTICE: This electronic transmission may contain confidential information. This information is intended for the use of the individual(s) or entity to whom it is intended, even if addressed incorrectly. This information should not be read, given or made accessible to anyone else. Please delete it from your files if you are not the intended recipient. If you have received this electronic transmission in error, please notify the sender immediately via the address shown. Thank you for your compliance.
_______________________________________________
ietf-calsify mailing list
ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Cyrus Daboo | 14 Jan 17:37 2010

[ietf-calsify] RFC5546 is out

Hi folks,
iTIPbis is now RFC 5546 (<http://tools.ietf.org/html/rfc5546>). It was 
actually published at the end of last year but for some reason the actual 
announcement message got lost (RFC editor said they would try and re-post 
it).

Thanks to everyone who helped out with this revision.

--

-- 
Cyrus Daboo
Eliot Lear | 14 Jan 17:52 2010
Picon

Re: [ietf-calsify] RFC5546 is out

Congratulations, Cyrus, on a great job!

Eliot

On 1/14/10 5:37 PM, Cyrus Daboo wrote:
> Hi folks,
> iTIPbis is now RFC 5546 (<http://tools.ietf.org/html/rfc5546>). It was 
> actually published at the end of last year but for some reason the actual 
> announcement message got lost (RFC editor said they would try and re-post 
> it).
>
> Thanks to everyone who helped out with this revision.
>
>   
Alexey Melnikov | 30 Jan 00:38 2010

Re: WGLC for draft-ietf-calsify-rfc2447bis-07.txt

Cyrus Daboo wrote:
Hi,
Hi Cyrus,
Thank you for the review. My belated response:
--On December 1, 2009 2:21:03 PM +0100 Eliot Lear <lear <at> cisco.com> wrote:
We are entering working group last call for
draft-ietf-calsify-rfc2447bis-07.txt, iMIP.  At this time I would ask you
to please identify any outstanding issues you have with the draft, if you
have not already done so.  I am in the process of checking all examples.
You can find a copy of the draft at
http://tools.ietf.org/html/draft-ietf-calsify-rfc2447bis-07.
My review:

- Abstract: change '(iCAL)' to '(iCalendar)'.

- Introduction: change 'over MIME as defined in' to 'over Internet email (using MIME) as defined in'.
Both changed, thanks.
- §2: The terminology for "originator" and "respondent" are a little messy. As per iTIP. "originator" is the person sending the message. That could be the ORGANIZER or ATTENDEE. iTIP does not have the concept of a "respondent", but rather uses "recipient" to refer to the use receiving the scheduling message (and that too could be either the ORGANIZER or an ATTENDEE). Since "respondent" is really only used in one place I suggest we remove it and replace it with "recipient" in §2.2.1. Then the following should be done:

-- §2, ¶2 & ¶3 change to:

   The sections below refer to the "originator" and the "recipient" of an
   iMIP message. In the case of a "request" method, the originator is the
   "Organizer" and the recipient is an "Attendee" of the event. In the
   case of a "response" method, the originator is an "Attendee" and the
   recipient is the "Organizer" of the event.

   The [RFC-5322] "Reply-To" header typically contains the email address
   of the originator of the scheduling message. However, this cannot be
   guaranteed as Mail User Agents (MUA) are not required to enforce iMIP
   semantics.
Ok, I used your text.
- §2, ¶3 - why is Reply-to even mentioned here? If it is mentioned, why is there no discussion on what goes in the From or To fields? I think this is something lacking in the spec. What is more there needs to be a clear statement that when a recipient replies to a scheduling message with another scheduling message (as opposed to a "regular" email message), they MUST use the addressing information in the iCalendar data and not that in the email headers (i.e. discard From:, Reply-To: etc).
I am still thinking about the best way of dealing with this.
- §2.2.1, ¶3: why is the reference to "[RFC-1847]" at the start?
Hmm. To qualify "message flow"?
- §2.3, ¶1: change 'the "ATTENDEE" property' to 'the "ORGANIZER" and "ATTENDEE" properties'

- §2.4 title: change 'Content Type' to 'Content-Type'.
Changed.
- §2.4: this has terms like '"method" parameter' when referring to a MIME header parameter. But the main terminology section stated that iCalendar parameters would appear in lower case with the work "parameter" after them. So there is the potential for confusion here (we have the same issue with CalDAV and iCalendar and "property"). I suggest we change the document to use upper case for the iCalendar parameters, which matches how those are displayed in iCalendar and iTIP. Also, when talking about MIME parameters, we should explicitly state "MIME parameter" rather than just "parameter".
I've tried to do that, but I am not sure if I've done it consistently in the document. Please check the following version.
- §2.4, ¶10: missing reference '<<add ref>>'.
This required some digging. I've added a reference to Content-Language header field.
- §2.5 Example: change 'ACME' to 'example.com' - do that for all examples.
I've changed to use:
PRODID:-//Example/ExampleCalendarClient//EN as in RFC 5546.
- §3, ¶1: comment left at the end of the paragraph needs to be addressed.
Can you recommend some specific text?
- §3, ¶4: change 'Section 3 of [iTIP]' to 'Section 1.4 of [iTIP]'.

- §4.3 title: 'Inline Attachment' is confusing as iCalendar refers to "inline attachments" as ones where the attachment data is directly in the iCalendar property. I suggest just removing 'and Inline Attachment' from the end of the title.
Changed.
_______________________________________________
calsify mailing list
calsify <at> ietf.org
https://www.ietf.org/mailman/listinfo/calsify

Gmane