Re: [calsify] Roadmap for JsCalendarbis, iTip and iMip

[Michael Douglass <[e-mail]>]

Sorry not to have replied earlier...

Cutting to the bottom my preference is a single valued property for the 
scheduling address and the participant addresses.

Other than the separation of scheduling address and organizer role this 
is compatible with iTip and might be sufficient for other protocols - if 
any appear. If not we can deal with it then. Simplicity and 
compatibility is the key for the moemnt.

On 7/7/22 04:52, Robert Stepanek wrote:
> On Mon, Jul 4, 2022, at 8:23 AM, Neil Jenkins wrote:
>> On Tue, 28 Jun 2022, at 8:57 PM, Robert Stepanek wrote:
>>> The gist: These complications all come from the over-specified 
>>> "imip" protocol and the underspecified "other" protocol,
>>
>> My original thought was that we would define a different property for 
>> each iTIP binding. For example, you might support both implicit iTIP 
>> over CalDAV with an internal URI, and also an iMIP binding with a 
>> mailto URI. [...]
>> A generic |itip| protocol as Robert suggested could work too but 
>> seems a bit less useful.
>
> I see how it is less useful for the use cases you described. It does 
> bring the benefit though to be fully aligned with the currently 
> restricted iCalendar model. With the latest recharter of the working 
> group, it understand that both JSCalendar and iCalendar are expected 
> to work on common calendaring semantics and data model, having the 
> same expressivity. Introducing what you describe above in JSCalendar 
> will need more work to make it happen also in iCalendar and iTIP.
>
>> In terms of mapping a multi-value property to single valued iCalendar 
>> ATTENDEE, I guess you just have to define an order of precedence to 
>> choose one. (And store the full set in a PARTICIPANT component.)
>
> I am not much of a fan of heuristics when defining the mapping, 
> especially not when it comes to crucial parts such as scheduling. 
> First, sticking the order of precedence into the standard bears the 
> risk of getting out of date. Second, it should be as simple as it gets 
> when mapping the scheduling properties between formats. I would expect 
> a good number of implementations use an external library to map 
> between JSCalendar and iCalendar, and these libraries typically will 
> have no insight into what use cases they are for.
>
> The deadline for draft submissions for IETF 114 is getting very close 
> now: Do we have consensus on any of the discussed options (keep as-is, 
> keep multi-valued but use |itip|, change to single-valued property)? 
> If so, I will try to update the jscalendarbis draft accordingly before 
> the deadline. If not, we will continue the discussion here and during 
> the calext session.
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify