Subject: [calsify] Asking for feedback on an idea for an RFC5545 extension

From: "Tim Hare" <[email-masked]>
Date: Tue, 18 Jun 2019 22:57:05 -0400

Before I go through trying to write up an RFC document, I thought I'd float
the idea here first and ask for feedback.

I would like to propose a new component,  INCLUDE, at the BEGIN:VCALENDAR
level (the same level as PRODID: )

INCLUDE would have a value that was a URI  referencing iCalendar object.
Implementations would read in that object, discard the "envelope"
(BEGIN:VCALENDAR / END:VCALENDAR, VERSION, PRODID) and add the other items
to the current object.

One use case:  when an organization maintains calendars for several
different parts, but would also like to include all of it at once.   For
example -  a senior center maintains one calendar for language classes, one
calendar for meals, one calendar for special events.   The sub-organizations
maintaining these calendars only need to see their calendars, but to publish
to the public all of it needs to be seen.  With VINCLUDE this "overall"
calendar object would be

BEGIN:VCALENDAR
VERSION:2.0

PRODID:SeniorCalendar1.5
INCLUDE: https://seniorcenter.org/calendars/language.ics

INCLUDE: https://seniorcenter.org/calendars/meals.ics

INCLUDE: https://seniorcenter.org/calendars/events.ics

BEGIN:VEVENT

. other VEVENTS in this calendar
END:VEVENT

END:VCALENDAR

Obviously this idea needs to be "fleshed" out, and some issues looked at -
such as how to handle an INCLUDE of an object that also has INCLUDE(s) - but
I see utility in this idea and other places it could be used.  If there are
others who think it's worth the effort I will try to work on an extension
RFC for it.

Thanks for any and all feedback
Tim Hare
Interested Bystander, Non-Inc.

---

From: Дилян Палаузов <[email-masked]>
Date: Thu, 20 Jun 2019 18:23:52 +0000

Hello Tim,

to elaborate on your uses case:
- the users want to import in their CUA one calender (iCalendar object), or actually an URL to that object, but get
updates from three calenders, whenever they change.
- the use case is for the HTTP(S) schema, although FTP would in theory also work.

The current approach for the use case you described, is:
- the user registers to a server, per RFC 6764.  The server communicates to the client which calendars it offers, here
three calendars, and the user choses from the list which calendars they want to subscribe.  Clicking on five calendars,
out of five offered, is not a big deal, neither is selecting five out of ten calendars offered.

What is the problem with the approach per RFC6764?

I do not know if this scales for 100 calendars and if there is a use case for 100 calendars.

That said I do not see the added value of INCLUDE in the use case you provided.

There are other in considerations, covering the same use case:
- webcal subscriptions, where the user provides a server/domain name and the server communicates to the client to which
calenders the user is subscribed.  Lets say, this can be used by the server to communicate to the client the subscribed
calenders by default, and the user can unregister from each of them
- webdav sharing (https://tools.ietf.org/html/draft-pot-webdav-resource-sharing-04), just without the Notification part
and without the calendar sharing (scheduling) parts and without the invitations.

Greetings
  Дилян

On Tue, 2019-06-18 at 22:57 -0400, Tim Hare wrote:
> Before I go through trying to write up an RFC document, I thought I’d float the idea here first and ask for feedback.
>  
> I would like to propose a new component,  INCLUDE, at the BEGIN:VCALENDAR level (the same level as PRODID: )
> 
> INCLUDE would have a value that was a URI  referencing iCalendar object. Implementations would read in that object, discard the “envelope”  (BEGIN:VCALENDAR / END:VCALENDAR, VERSION, PRODID) and add the other items to the current object.
> 
> One use case:  when an organization maintains calendars for several different parts, but would also like to include all of it at once.   For example -  a senior center maintains one calendar for language classes, one calendar for meals, one calendar for special events.   The sub-organizations maintaining these calendars only need to see their calendars, but to publish to the public all of it needs to be seen.  With VINCLUDE this “overall” calendar object would be
> 
> BEGIN:VCALENDAR
> VERSION:2.0
> PRODID:SeniorCalendar1.5
> … other VEVENTS in this calendar
> END:VEVENT
> END:VCALENDAR
>  
>  
> Obviously this idea needs to be “fleshed” out, and some issues looked at – such as how to handle an INCLUDE of an object that also has INCLUDE(s) - but I see utility in this idea and other places it could be used.  If there are others who think it’s worth the effort I will try to work on an extension RFC for it.
>  
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify