Re: [calsify] draft-ietf-calext-jscalendar and participants

[Michael Douglass <[e-mail]>]

On 2/16/21 21:50, Neil Jenkins wrote:
> On Wed, 17 Feb 2021, at 04:17, Robert Stepanek wrote:
>>> For example I might have an ATTENDEE that looks like
>>> ATTENDEE;CN=Michael 
>>> Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHAIR;EMAIL=[e-mail] 
>>> <mailto:[e-mail]>:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOhcljjCSqMYrUXDcs6f1z7CyXejTR/principal/
>> The difference is that the participant id has no meaning outside a 
>> single JSEvent. But a calendar user address is an identifier for an 
>> entity across events.
>>
>> It allows for unambigously mapping the ATTENDEE or ORGANIZER property 
>> value to JSCalendar and reverse. It's not clear from a multi-valued 
>> sendTo property which one should be used as the property value.
>
> My reading of the current RFCs, although I think they are not super 
> clear, is that the calendar user address is the only "sendTo" method. 
> An email may be specified in addition but this is not intended as an 
> iMIP destination (so would not be in the JSCalendar sendTo, just the 
> participant's email property). Is your interpretation that the 
> calendar user address is more like a uid? If so, can you use it for 
> anything other than as an opaque token for equality comparison?

5545 only requires that the calendar address be a URI - it does not 
require it be a mailto URI - UNLESS it is used as the destination for email.

The ATTENDEE and ORGANIZER properties typically had a mailto uri as a 
value. When it was decided that the value should NOT be a mailto there 
was clearly a need for somewhere to put the address of the user so iMip 
could be sent - that's the EMAIL parameter. I don't see anything that 
suggests the calendar-address is no longer the identifier for the property.

5545 and 5546 very likely have no mention of an email address other than 
the mailto uri in the value because there was no EMAIL parameter at the 
time.

>
>> There is one other benefit of making more use of calendar user 
>> addresses in JSCalendar: the DELEGATED-FROM, DELEGATED-TO, MEMBER-OF, 
>> SENT-BY parameters all use calendar user addresses. But in JSCalendar 
>> we use participant ids for these properties. If a DELEGATED-FROM 
>> calendar user address has no ATTENDEE in iCalendar, we would need to 
>> create an artificial participant in JSCalendar. This participant 
>> could have an "informational" role, expectReply=false, because it's 
>> really not a participant. When mapping back to iCalendar we would 
>> need to figure out if to create an ATTENDEE for that. When we use 
>> calendar user addresses rather than participant ids for these 
>> properties then there is no ambiguity.
>
> It seems a bit weird to me that you would have unresolvable 
> identifiers like this (they don't seem particularly useful).
Any UID is intended to be an unresolvable identifier - doesn't make them 
any less useful.
> I'd also say that you'd be making the JSCalendar object more awkward 
> to work with (you'd have to linearly scan or build a separate index to 
> get from one of these pointers to the participant it refers to). I 
> would generally say a slightly more cumbersome translation is 
> preferable to all objects in the new format being harder to use.
It was precisely because I was having to do that that I raised the 
issue. The jscalendar spec DOES NOT specify that the id for a 
participant is the calendar address and the examples don't show it either.

What concerns me is that jscalendar seems to be essentially rewriting 
iTip - perhaps not intentionally.

We currently have 2 'properties' - the iCalendar attendee value - a 
calendar user address and an email address which may be the same or 
specified in the EMAIL parameter.

I do believe the EMAIL parameter to be underspecified but nothing in the 
text leads me to believe it is intended to replace the calendar address.

If we add a jscalendar calendarAddress property the mapping is simple 
and what works now will continue to work.

We *could* try some experiments and mess around with the values but if 
we don't have an easy reversible mapping between jscalendar and 
icalendar things will almost certainly break.


>
> Neil.
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify