Subject: [Ietf-calsify] status of RFC 2445bis

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Jul 2008 14:24:18 +0200

Lisa, Bernard, Aki, all:

I've held off sending this note because Bernard was on holiday last 
week.  Here is my understanding of the AD issues:

AD Issue 1:

A disagreement between Bernard and everyone else.  Bernard, rough 
consensus says that you should change the text accordingly.

AD Issue 2:

There needs to be a statement as to what URIs are allowed and how they 
are to be resolved (in the case of HTTP and HTTPs).

AD Issue 3:

Bernard has come up with what seems like sufficient grounds to leave 
things as they are in the draft.

AD Issue 4:

Bernard has requested text, but there is consensus that text is needed 
and we are currently blocking on that.

I would like to see this draft move forward quickly after IETF.  
Bernard, can you please address each issue in an update?

Thanks,

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

---

From: "Tim Hare" <[email-masked]>
Date: Wed, 23 Jul 2008 09:40:25 -0400

Lisa Dusseault had proposed some text:

>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.

Bernard Desruisseaux had stated previously:

>Things that should be noted:
>
>1- iTIP does not allow different component types to be mixed.

I believe multiple component types should be allowed within ITIP for certain
METHOD: values, PUBLISH being the first that comes to mind, (although for
one of the use cases, moving the entire contents of a calendar, a new method
type  of TRANSPORT might be in order).

I would reword suggest slightly different wording for Lisa's last paragraph
(although this could use some work, too, I fear):

NEW:

Some applications provide a function to read iCalendar objects in a
non-scheduling context, for example to import a copy of a calendar which was
exported for backup. These applications SHOULD support iCalendar objects
which contain several different component types as long as the types are
valid component types defined in this document. Applications which import
iCalendar objects and  which do not process all of the component types in an
iCalendar object SHOULD inform the user that some components were ignored,
and SHOULD inform the user or create a log of which components were ignored.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Wednesday, July 23, 2008 8:24 AM
To: Bernard Desruisseaux; Lisa Dusseault; Aki Niemi;
[email-masked]
Subject: [Ietf-calsify] status of RFC 2445bis

Lisa, Bernard, Aki, all:

I've held off sending this note because Bernard was on holiday last week.
Here is my understanding of the AD issues:

AD Issue 1:

A disagreement between Bernard and everyone else.  Bernard, rough consensus
says that you should change the text accordingly.

AD Issue 2:

There needs to be a statement as to what URIs are allowed and how they are
to be resolved (in the case of HTTP and HTTPs).

AD Issue 3:

Bernard has come up with what seems like sufficient grounds to leave things
as they are in the draft.

AD Issue 4:

Bernard has requested text, but there is consensus that text is needed and
we are currently blocking on that.

Thanks,

Eliot