Subject: [calsify] jscalendar - participants and contacts

From: Michael Douglass <[email-masked]>
Date: Thu, 7 May 2020 22:13:57 -0400

To try to summarize...

My concerns with this are:

1. There's no obvious place at the moment to put contacts

2. After 10 years with eventpub I'd like to ensure that jscalendar is 
compatible with that draft.

After much discussion we'd come to state we are in now - a PARTICIPANT 
component that can represent people/groups etc that participate in the 
event - not necessarily attendees, cold be spectators, coaches, scenery 
shifters, piano tuners.

This reflects some practice I'd seen and which others had been emulating 
through x-properties and such.

The eventpub participant doesn't try to take on all the features of 
attendees simply for backwards compatibility. For attendees a 
PARTICIPANT component provides additional data but clients not aware of 
the PARTICIPANT will continue to work.

I'm ok with treating the jscalendar "roles" as equivalent to the 
eventpub PARTICIPANT-TYPE but it also seems closer in some ways to the 
jscalendar "kind".

I do think we could use the linkids as a way of referring to e.g. a 
vcard to provide more detail. In both jscalendar and eventpub we need a 
plain text property to hold simple plaintext values - e.g a phone 
number. Eventpub already has the DESCRIPTION property - could we add 
that to jscalendar participant?

With that in place - not only could we map the current CONTACT property 
but also be compatible with the eventpub PARTICIPANT component.

In passing - Robert suggested just making some of these a simple link - 
eventpub already went through that iteration and it was soundly rejected 
-  key calendar properties should not be represented as just linked data 
was the argument.

Some examples (from 5545):

CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234

...
"participants": {
...
   "dG9tQGZvb2Jhci5xlLmNvbQ": {
          "@type": "Participant",
          "roles": {
            "contact": true
          },
	"description": "Jim Dolittle, ABC Industries, +1-919-555-1234"
        },
...
}

CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\,
  c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
  +1-919-555-1234

...
"participants": {
...
   "dG9tQGZvb2Jhci5xlLmNvbQ": {
          "@type": "Participant",
          "roles": {
            "contact": true
          },
         "linkIds": {
	     "dG9tQGZvb2Jhci5xlLmNvbQl1": true
	},
	"description": "Jim Dolittle, ABC Industries, +1-919-555-1234"
        },
...
},
"links": {
	"dG9tQGZvb2Jhci5xlLmNvbQl1": {
             "@type": "Link",
	    "href": "ldap://example.com:6666/o=ABC%20Industries,c=US???(cn=Jim%20Dolittle)",
	    "rel": "what?"
	 }
}

CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim
  Dolittle\, ABC Industries\, +1-919-555-1234

Much the same but needs a different "rel"

---

From: "Robert Stepanek" <[email-masked]>
Date: Fri, 08 May 2020 11:19:00 +0200

On Fri, May 8, 2020, at 4:13 AM, Michael Douglass wrote:
> I do think we could use the linkids as a way of referring to e.g. a vcard to provide more detail. In both jscalendar and eventpub we need a plain text property to hold simple plaintext values - e.g a phone number. Eventpub already has the DESCRIPTION property - could we add that to jscalendar participant?

Right. So this would require to:

- add a description property to Participant
- add "contact" to the IANA JSCalendar Enum Registry for Participant roles
- add "contact" to the IANA Link Relations Registry

This sounds OK for me. Probably Neil wants to chime in.

An iCalendar CONTACT property is allowed to either have a free text value or a URI. If its value is a valid URI then it must map in JSCalendar to a Link (e.g. a Participant description must not contain only a URI).

> CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\,
 c=US???(cn=Jim%20Dolittle)" <ldap://example.com:6666/o=ABC%20Industries\,c=US???(cn=Jim%20Dolittle)>:Jim Dolittle\, ABC Industries\,
 +1-919-555-1234

[...]

"links": {

> Much the same but needs a different "rel"

Why would the rel be different? In you example I see that the ALTREP parameters have different URI schemes (and the data most likely different media types). But RFC8288 states in section 2.1 [1]: "Relation types are not to be confused with media types [RFC2046]; they do not identify the format of the representation that results when the link is dereferenced."

[1] https://datatracker.ietf.org/doc/html/rfc8288#section-2.1

---

From: Michael Douglass <[email-masked]>
Date: Sun, 10 May 2020 00:02:03 -0400

On 5/8/20 05:19, Robert Stepanek wrote:
>> vcard to provide more detail. In both jscalendar and eventpub we need 
>> a plain text property to hold simple plaintext values - e.g a phone 
> An iCalendar CONTACT property is allowed to either have a free text 
> value or a URI. If its value is a valid URI then it must map in 
> JSCalendar to a Link (e.g. a Participant description must not contain 
> only a URI).

No - the only valid value is a TEXT value. It does say:

       The property value consists of textual contact
       information.  An alternative representation for the property value
       can also be specified that refers to a URI pointing to an
       alternate form, such as a vCard [RFC2426  <https://tools.ietf.org/html/rfc2426>], for the contact
       information.

It's referring there to the ALTREP parameter which I handled in the 
examples by use of a link

>
>
>> CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\, c=US???(cn=Jim%20Dolittle)"  <ldap://example.com:6666/o=ABC%20Industries\,c=US???(cn=Jim%20Dolittle)>:Jim Dolittle\, ABC Industries\,
>>   +1-919-555-1234
>>
>> [...]
>>
>> "links": {
>> 	    "href":"ldap://example.com:6666/o=ABC%20Industries,c=US???(cn=Jim%20Dolittle)"  <ldap://example.com:6666/o=ABC%20Industries,c=US???(cn=Jim%20Dolittle)>,
>> 	    "rel": "what?"
>> 	 }
>> }
>>
>>
>> CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf"  <http://example.com/pdi/jdoe.vcf>:Jim
> Why would the rel be different? In you example I see that the ALTREP 
> parameters have different URI schemes (and the data most likely 
> different media types). But RFC8288 states in section 2.1 [1]: 
> "Relation types are not to be confused with media types [RFC2046]; 
> they do not identify the format of the representation that results 
> when the link is dereferenced."

Ok - I'll buy that - but should the rel be "contact"? It's an 
alternative representation of the property. Can we just call it 
"alternativeRepresentation".

Which does lead to what do we do with ALTREP elsewhere - DESCRIPTION can 
have one.

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

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 11 May 2020 14:43:07 +1000

> This sounds OK for me. Probably Neil wants to chime in.

That sounds fine to me too.

Neil.