Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 04 Jul 2008 11:05:48 -0400

It's not clear to me what Lisa is suggesting actually.

a) Warning about the fact that components type can be mixed?
b) Not to ignore unsupported component types silently?

Proposed text would be great!

Things that should be noted:

1- iTIP does not allow different component types to be mixed.

2- CalDAV provides means to get only the components types that you want.

As such, in practice we will only see mixed component types in export 
scenarios and Internet calendars (aka, webcal).

Cheers,
Bernard

Eliot Lear wrote:
> I believe we have consensus as to Lisa's suggestion.  Any disagreement?
> 
> Eliot
> 
> Tim Hare wrote:
>> As an "informed user" - i.e. not a developer, I definitely support
>> NON-silent rejection.  I can agree with non-support of certain components
>> only if I receive some notification;  due to work requirements I am now
>> journalling my time on some projects, and it would be good to know if I
>> can't import that data into another tool.
>>
>>
>> Tim Hare
>> Interested Bystander, Non-Inc.
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Cyrus Daboo
>> Sent: Monday, June 16, 2008 12:33 PM
>> To: Lisa Dusseault
>> Cc: [email-masked]; Bernard Desruisseaux
>> Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in 
>> thesame
>> iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)
>>
>> Hi Lisa,
>>
>> --On June 16, 2008 9:25:14 AM -0700 Lisa 
>> Dusseault<[email-masked]>
>> wrote:
>>
>>   
>>>> The suggestion of an implementation note that describes the "common
>>>> use" of the components and explains that some may be supported and
>>>> others not is fine. In fact telling implementors that they need to be
>>>> prepared for another system to reject a component would be good.
>>>>        
>>> I can get behind that.  I'd also like to recommend that systems not
>>> reject a component silently -- a user needs to know if they imported a
>>> iCalendar file and lost 50 VJOURNAL components in the process.
>>>      
>>
>> Agreed.
>>
>> Note that iTIP does have a status code for "Unsupported Component" 
>> (3.13) -
>> so informing the originator of the iCalendar data that they are sending
>> something that is not supported by the recipient is covered by that.
>>
>> -- 
>> Cyrus Daboo
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>>    
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 4 Jul 2008 16:17:17 -0400

I can't speak for Lisa, but the export/import scenario is one place where b)
applies.  If by "Internet calendar" you mean an .ics file that is opened via
browser, that is also an 'import' scenario I think. 

Tim Hare

-----Original Message-----
From: Bernard Desruisseaux [mailto:[email-masked]] 
Sent: Friday, July 04, 2008 11:06 AM
To: Eliot Lear
Cc: Tim Hare; [email-masked]
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame

Cheers,
Bernard

Eliot Lear wrote:
>> NON-silent rejection.  I can agree with non-support of certain 
>> components only if I receive some notification;  due to work 
>> requirements I am now journalling my time on some projects, and it 
>> would be good to know if I can't import that data into another tool.
>>
>>
>> Tim Hare
>> thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review 
>> on2445bis)
>>
>> Hi Lisa,
>>
>>>> others not is fine. In fact telling implementors that they need to 
>>>> be prepared for another system to reject a component would be good.
>>>>        
>>> reject a component silently -- a user needs to know if they imported 
>>> a iCalendar file and lost 50 VJOURNAL components in the process.
>>>      
>>
>> Agreed.
>>
>> so informing the originator of the iCalendar data that they are 
>> sending something that is not supported by the recipient is covered by
that.

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 14 Jul 2008 15:49:21 -0700

Yes, it's the import scenarios I had in mind.  Even if it's not  
strictly Internet Engineering.

Off the top of my head, suggested text change that can certainly be  
improved upon, particularly the hand-wavy "other situations":

OLD:

    An iCalendar object MUST include the "PRODID" and "VERSION" calendar
    properties.  In addition, it MUST include at least one calendar
    component.  Special forms of iCalendar objects are possible to
    publish just busy time (i.e., only a "VFREEBUSY" calendar component)
    or time zone (i.e., only a "VTIMEZONE" calendar component)
    information.  In addition, a complex iCalendar object that is used  
to
    capture a complete snapshot of the contents of a calendar is  
possible
    (e.g., composite of many different calendar components).  More
    commonly, an iCalendar object will consist of just a single  
"VEVENT",
    "VTODO" or "VJOURNAL" calendar component.  Applications MUST ignore
    x-comp and iana-comp they don't recognized.

NEW:

    An iCalendar object MUST include the "PRODID" and "VERSION" calendar
    properties.  In addition, it MUST include at least one calendar
    component.   Applications MUST ignore
    x-comp and iana-comp they don't recognized.

	When iCalendar objects are sent out using iTIP, these usually
    consist of just a single "VEVENT", "VTODO" or "VJOURNAL" calendar
    component.  The recipient is expected to support any of these.  In  
other
    situtations, iCalendar objects may contain only a "VFREEBUSY"
    or "VTIMEZONE" calendar component.  Finally, complex iCalendar
    objects containing several different calendar components are used
    to capture a complete snapshot of the contents of a calendar, task  
list,
    project file or other application construct.

    Applications that support importing iCalendar objects SHOULD
    support all of the component types defined in this document, and
    SHOULD NOT silently drop any components as that can lead
    to user data loss.

Lisa