Subject: Re: [calsify] Updated JSCalendar draft version 07

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 01 Oct 2018 11:34:28 -0400

On Thu, Sep 27, 2018, at 03:46, Neil Jenkins wrote: 
> On Thu, 20 Sep 2018, at 7:55 PM, Robert Stepanek wrote: 
>>  * The id of a Participant object in the `participants` property now must be a valid URI. 
>  
> I don't like this because it's different to how these kind of set-of-items properties (e.g. locations, alerts) work in two imporant ways: 
>  * It means the id has semantic value. 
>  * It means the id has different allowed character restrictions compared to these other objects. 
 
I agree, my original proposal didn't turn out well when I implemented it in our experimental JSCalendar server implementation. 
 
> I suggest that instead we add a new `sendTo` property on the participant object, with a value in the same format as the `replyTo` JSEvent property.  
 
During CalConnect XLIII, which just happened in Karlsruhe last week, we had discussed defining both `email` and `uri` properties on the Participant object. However, I prefer your proposed `sendTo` property, as it is aligned with the `replyTo` property, covers all we could achieve with two separate properties, and is more straight-forward to extend. 
 
Using ORGANIZER and ATTENDEE property values and the RFC7986 EMAIL parameter this should map nicely for the majority of use cases between JSCalendar and iCalendar. 
 
There is however an issue with the URI template in the `other` channel: there isn't exactly one item to uniquely identify a participant for this object, so how to extend the `participantId` variable isn't clear. The previous definition of the URI template assumed the email property to always be set, but that isn't the case any more. It could be that either the `imip` of `other` sendTo channels are set, or even both. Which one should be it, and how to deal with empty values? Using the id of the Participant object in the participants property again would give this id semantic value, which I agree to avoid. 
 
The solution might be to get rid of the `participantId` URI template variable: Implementations sending out invitations could generate a separate `replyTo{other}` URI for each invitee if they prefer, and client implementations similarly may generate a `sendTo{other}` URI encoding the participant in the chosen URI scheme. I still intend to keep the `uid`, `sequence` and `recurrenceId` URI template variables as they are clearly useful and uncritical to encode in a URI level 1 template. 
 
I plan to send out an updated RFC draft this week, so please jump in if you other ideas! 
 
Cheers, 
Robert

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 01 Oct 2018 11:51:56 -0400

> The solution might be to get rid of the `participantId` URI template variable: Implementations sending out invitations could generate a separate `replyTo{other}` URI for each invitee if they prefer…
 
Having thought more about this, I hit "Send" to soon! 
 
The URI template in JSCalendar replyTo{other} is neat, but mixing it up with the CAL-ADDRESS value of the iCalendar definitions is asking for trouble: 
 
RFC 6570 clearly states 

   URI Templates are not URIs: they do not identify an abstract or
   physical resource, they are not parsed as URIs, and they should not
   be used in places where a URI would be expected unless the template
   expressions will be expanded by a template processor prior to use.
 
and indeed it's not entirely clear to me how we would map them to iCalendar URIs in the ORGANIZER and ATTENDEE properties for recurring events. 
 
So I actually tend to remove the URI template definition from the replyTo{other} and sendTo{other} property values. The URI template variable came up as an idea when we had planned to allow for a web form, and client implementations could reasonably expect to extend the email URI variable into the URL path and do a GET on the web form address. The semantics of this property now shifted considerably. We could still think about adding support for this web replyTo channel, but it might not need to be part of the core spec. 
 
Cheers, 
Robert

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 02 Oct 2018 03:00:45 -0400

On Tue, 2 Oct 2018, at 1:52 AM, Robert Stepanek wrote: 
> So I actually tend to remove the URI template definition from the replyTo{other} and sendTo{other} property values. 
 
Just to clarify, are you going to just make it a straight (non-template) URI? That seems reasonable and worthwhile to me (here's a URL that you can open in a browser to go RSVP to this event). Any template-stuff can be a further extension. 
 
Neil.

---

From: "Robert Stepanek" <[email-masked]>
Date: Tue, 02 Oct 2018 04:34:25 -0400

> Just to clarify, are you going to just make it a straight (non-template) URI? That seems reasonable and worthwhile to me (here's a URL that you can open in a browser to go RSVP to this event). Any…
 
Yes. As a minimum I will the define "imip" channel which MUST be a mailto: URI, and the "other" channel which may be any URI. 
 
During CalConnect one participant brought up the question if any http URI can be expected to be a web form to open with a GET request - which the "other" URI obviously can't guarantee. So it might make sense to define a special "web" replyTo with clearly defined expectations. This specific replyTo channel might benefit from a URI template. 
 
Cheers, 
Robert

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 02 Oct 2018 06:02:33 -0400

On Tue, 2 Oct 2018, at 6:34 PM, Robert Stepanek wrote: 
> During CalConnect one participant brought up the question if any http URI can be expected to be a web form to open with a GET request - which the "other" URI obviously can't guarantee. So it might make sense to define a special "web" replyTo with clearly defined expectations. 
 
That sounds sensible to me. I still don't think it necessarily needs to be a template though: you just open the URL and give your response on the webpage. The organiser can send different URLs to different attendees if necessary. 
 
Neil.

---

From: Andri Möll <[email-masked]>
Date: Tue, 2 Oct 2018 12:48:53 +0000

What does a "web form" mean? If a page saying "You're now going! Cancel 
instead?" is sufficiently a "form", how does that differ from having a 
HTTP URL (or any other URI for that matter) in "other" which also 
probably trigger default OS actions and require further user interaction?

On 10/2/18 10:02 AM, Neil Jenkins wrote:
>> During CalConnect one participant brought up the question if any http 
>> URI can be expected to be a web form to open with a GET request - 
>> which the "other" URI obviously can't guarantee. So it might make 
>> sense to define a special "web" replyTo with clearly defined 
>> expectations.
>
> That sounds sensible to me. I still don't think it necessarily needs 
> to be a template though: you just open the URL and give your response 
> on the webpage. The organiser can send different URLs to different 
> attendees if necessary.

---

From: "Robert Stepanek" <[email-masked]>
Date: Tue, 02 Oct 2018 09:04:37 -0400

On Tue, Oct 2, 2018, at 14:49, Andri Möll wrote: 
> What does a "web form" mean? If a page saying "You're now going! Cancel instead?" is sufficiently a "form", how does that differ from having a HTTP URL (or any other URI for that matter) in "other" which also probably trigger default OS actions and require further user interaction? 

A client may want to support web-based RSVP for its user, without passing any "other" URI to its OS handlers. The spec can more clearly define what to expect for a "web" replyTo, but it has to keep the definition of "other" generic for iCalendar backwards compatibility . Even for a HTTP URL in "other", the client can't make any assumptions about what's behind it, it could be the URL of a CalDAV principal, or whatever. 
 
Cheers, 
Robert

---

From: Andri Möll <[email-masked]>
Date: Tue, 2 Oct 2018 13:15:54 +0000

On 10/2/18 1:04 PM, Robert Stepanek wrote:
>> What does a "web form" mean? If a page saying "You're now going! 
>> Cancel instead?" is sufficiently a "form", how does that differ from 
>> having a HTTP URL (or any other URI for that matter) in "other" which 
>> also probably trigger default OS actions and require further user 
>> interaction?
>>
>
> A client may want to support web-based RSVP for its user, without 
> passing any "other" URI to its OS handlers. The spec can more clearly 
> define what to expect for a "web" replyTo, but it has to keep the 
> definition of "other" generic for iCalendar backwards compatibility . 
> Even for a HTTP URL in "other", the client can't make any assumptions 
> about what's behind it, it could be the URL of a CalDAV principal, or 
> whatever.
Handle a web URL without passing to the OS by opening a web view within 
the app? Okay, but why wouldn't they do the same for all HTTP URLs in 
"other"? If a client can't even make the assumption that they can show 
HTTP URLs in browsers, what is it for? If it _is_ expected for a client 
to show [all] HTTP URLs in the UI with buttons similar to "Respond via 
Web", then everyone will still have to concatenate the "web" URL to all 
"other" HTTP URLs and we're back to what led "web" to be merged to 
"other" in the first place. :P

---

From: "Robert Stepanek" <[email-masked]>
Date: Tue, 02 Oct 2018 09:31:34 -0400

On Tue, Oct 2, 2018, at 15:16, Andri Möll wrote: 
>>> What does a "web form" mean? [...] 

>>  
>> A client may want to support web-based RSVP for its user, without passing any "other" URI to its OS handlers. The spec [...] 
> Handle a web URL without passing to the OS by opening a web view within the app? Okay, but why wouldn't they do the same for all HTTP URLs in "other"? If a client can't even make the assumption that they can show HTTP URLs in browsers, what is it for?  
 
The "other" replyTo is what's needed to backwards-compatible handle non-mailto: URIs of iCalendar ATTENDEEs and ORGANIZERs. They can be any URI, and clients can only expect that the URI identifies the participant within this event. There's no requirement that the URI alone provides enough context to RSVP. E.g. a URI might be in the 'ldap' URI scheme, but the generic OS-registered LDAP client might have no idea what to do with that URI. 
 
We would rather not want to support generic URIs for RSVP, but that ship has sailed if we want to stay compatible with iCalendar in that matter (which we should IMO). 
 
>  
> If it _is_ expected for a client to show [all] HTTP URLs in the UI with buttons similar to "Respond via Web", then everyone will still have to concatenate the "web" URL to all "other" HTTP URLs and we're back to what led "web" to be merged to "other" in the first place. :P 
 
I'm not sure I'm reading "expected" right in your comment, so I'll clarify: there would be no requirement for clients that they MUST handle "web" replyTo. But if they decide to do, the spec defines this "web" replyTo explicitly enough, that a client can expect that passing this URL to a browser or some other web view will allow the user to interactively RSVP for this event. Does that make sense to you? 
 
Cheers, 
Robert

---

From: Michael Douglass <[email-masked]>
Date: Fri, 5 Oct 2018 00:44:55 -0400

Just a thought:

Java forms based login defines the form elements that must be present in 
the request to carry out a login.

There's no requirement that the client render any web content - it just 
has to get the credentials for the user and send them. Defining the 
required fields for a web service that handles replies would be the 
equivalent.

Of course that breaks the anti-spam trick of adding hidden fields that 
look like  the real fields and expecting replies on opaque or misnamed 
fields.

That's not a problem with login but might be here.

On the other hand many UI frameworks have the ability to render html - 
though they tend not to be up to date with current browsers.

On 10/2/18 09:31, Robert Stepanek wrote:
>>> passing any "other" URI to its OS handlers. The spec [....]
>> Handle a web URL without passing to the OS by opening a web view 
>> within the app? Okay, but why wouldn't they do the same for all HTTP 
>> URLs in "other"? If a client can't even make the assumption that they 
>> can show HTTP URLs in browsers, what is it for?
>
> The "other" replyTo is what's needed to backwards-compatible handle 
> non-mailto: URIs of iCalendar ATTENDEEs and ORGANIZERs. They can be 
> any URI, and clients can only expect that the URI identifies the 
> participant within this event. There's no requirement that the URI 
> alone provides enough context to RSVP. E.g. a URI might be in the 
> 'ldap' URI scheme, but the generic OS-registered LDAP client might 
> have no idea what to do with that URI.
>
> We would rather not want to support generic URIs for RSVP, but that 
> ship has sailed if we want to stay compatible with iCalendar in that 
> matter (which we should IMO).
>
>>
>> If it _is_ expected for a client to show [all] HTTP URLs in the UI 
>> with buttons similar to "Respond via Web", then everyone will still 
>> have to concatenate the "web" URL to all "other" HTTP URLs and we're 
>> back to what led "web" to be merged to "other" in the first place. :P
>
> I'm not sure I'm reading "expected" right in your comment, so I'll 
> clarify: there would be no requirement for clients that they MUST 
> handle "web" replyTo. But if they decide to do, the spec defines this 
> "web" replyTo explicitly enough, that a client can expect that passing 
> this URL to a browser or some other web view will allow the user to 
> interactively RSVP for this event. Does that make sense to you?
>
> Cheers,
> Robert
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify