Subject: [calsify] JSCalendar and eventpub - participant and contacts

From: Michael Douglass <[email-masked]>
Date: Wed, 29 Apr 2020 23:13:48 -0400

There's no mapping suggested for CONTACT which is vital for event 
publication. I'd suggest following the approach in eventpub - add a 
participantType property to jscalendar participant.

e.g.

"participantTypes": {"attendee": true}

Changing role "attendee" to "required" or "expected" might make sense also.

Also bringing jscalendar participant into line with eventpub extensions 
so we can do a consistent mapping between them.

This means adding the following to jscalendar:

order -  Positive number.
structuredData - with "encoding" and "value" properties.

The current CONTACT property is a plain text value and typically has no 
more than a phone number (which was one of the points of eventpub).

To deal with the current situation we need to have a place to put that 
phone number. As a fallback I considered encoding the value as a data uri.

I'm not that keen on the idea so perhaps we need a jscalendar and 
eventpub property to hold a plain-text value. I'd rather not call it 
value or text as both names turn up in parameters and types. plainText?

There are a couple of additional changes needed to eventpub: 
PARTICIPANT-TYPE needs to be allowed more than once and ATTENDEE should 
be added as a value.

Comments?

---

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 30 Apr 2020 15:28:06 +0200

Hi Mike,

On Thu, Apr 30, 2020, at 5:13 AM, Michael Douglass wrote:
> publication.

CONTACT allows both textual representation and a URI value. We could register a new "content" rel type at IANA and use a JSCalendar Link object? It could point to a VCARD, include free text in a data: URI (with an according text/plain contentType), or later also point to a JSCard.

> I'd suggest following the approach in eventpub - add a 

Wouldn't it be enough to map these participant types to a JSCalendar Participant role? All that would need to be done is to add their definition to the JSCalendar IANA Enum registry. The JSCalendar spec for Participant roles explicitly allows this.

> Changing role "attendee" to "required" or "expected" might make sense also.

The current spec already defines the attendee role as "the participant is expected to attend". Since it's a direct mapping of an iCalendar ATTENDEE, why not keep their naming in sync?

> This means adding the following to jscalendar:

Defining an order on arbitrary properties or values is indeed something that the current JSCalendar Participant does not provide. Which JSCalendar properties could be impacted by ORDER? For participant types, is there a well-defined order of types and can the order of same participant types differ between participants?

> structuredData - with "encoding" and "value" properties.

 I understand that STRUCTURED-DATA got introduced because ATTACH does not allow for text data. Wouldn't a JSCalendar Link object suffice? We might want to add an optional "schema" property to the Link object of type URI?

Cheers,
Robert

---

From: Michael Douglass <[email-masked]>
Date: Thu, 30 Apr 2020 12:31:19 -0400

Part of my concern here is to ensure that jscalendar is compatible with 
the eventpub work.

On 4/30/20 09:28, Robert Stepanek wrote:
> CONTACT allows both textual representation and a URI value. We could 
> register a new "content" rel type at IANA and use a JSCalendar Link 
> object? It could point to a VCARD, include free text in a data: URI 
> (with an according text/plain contentType), or later also point to a 
> JSCard.
>
> Wouldn't it be enough to map these participant types to a JSCalendar 
> Participant role? All that would need to be done is to add their 
> definition to the JSCalendar IANA Enum registry. The JSCalendar spec 
> for Participant roles explicitly allows this.
>
> The current spec already defines the attendee role as "the participant 
> is expected to attend".  Since it's a direct mapping of an iCalendar 
> ATTENDEE, why not keep their naming in sync?

I don't see it as a direct mapping. 5545 has a role of chair, required, 
optional or non-participant.

I think jscalendar has conflated type and role. What I'm suggesting is a 
more direct mapping. As we add more participant types other roles are 
likely to be needed.

And now I look again at eventpub I think I've done the same thing there 
with contacts. I defined the roles

      partvalue    = ("ACTIVE"
                      / "INACTIVE"
                      / "SPONSOR"
                      / "CONTACT"
                      / "BOOKING-CONTACT"
                      / "EMERGENCY-CONTACT"
                      / "PUBLICITY-CONTACT"
                      / "PLANNER-CONTACT"
                      / "PERFORMER"
                      / "SPEAKER"
                      / iana-token)     ; Other IANA-registered
                                        ; values

I think adding a PARTICIPANT-ROLE property might be better and more 
extensible.

> Defining an order on arbitrary properties or values is indeed 
> something that the current JSCalendar Participant does not provide. 
> Which JSCalendar properties could be impacted by ORDER? For 
> participant types, is there a well-defined order of types and can the 
> order of same participant types differ between participants?
For event publication it was felt useful to identify the more important 
participants of a given type (principal performer, main contact etc). 
For the purposes of mapping we can probably wait for this one.
>
>> structuredData - with "encoding" and "value" properties..
>
>  I understand that STRUCTURED-DATA got introduced because ATTACH does 
> not allow for text data. Wouldn't a JSCalendar Link object suffice? We 
> might want to add an optional "schema" property to the Link object of 
> type URI?

STRUCTURED-DATA got introduced because it was too risky - for backward 
compatibility reasons - to update ATTACH. It does allow us to carry a 
payload of well defined non-calendar data. link might do it with a 
schema property.

>
> Cheers,
> Robert
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 01 May 2020 13:52:03 +1000

/ "INACTIVE"
                     / "SPONSOR"
                     / "CONTACT"
                     / "BOOKING-CONTACT"
                     / "EMERGENCY-CONTACT"
                     / "PUBLICITY-CONTACT"
                     / "PLANNER-CONTACT"
                     / "PERFORMER"
                     / "SPEAKER"

Not sure what active/inactive are meant to mean, but the rest of these can all be registered as participant roles in the JScalendar Enum registry. We don't need a new property.

Neil.