Subject: Re: [calsify] ReplyTo with HTTP (for development)

From: Andri Möll <[email-masked]>
Date: Wed, 5 Sep 2018 20:14:02 +0000

This isn't about a shoddy service. This is about debugging 3rd party 
client software.

I've spent hours debugging and working around iOS's (and other 
platforms') CalDAV quirks and managed to so by directing the apps to a 
development machine. Yet if CalDAV had demanded HTTPS to the server, I 
would've been hosed. You can't get a legit certificate for a local IP 
address nor do I have a Mac to install custom root certificates to an 
iPhone, for example. If that's even a thing anymore. Some client 
software have their own bundled roots. There it would've impossible to 
productively debug HTTPS-only services.

This is a weird thing for me to advocate, as I'm usually the first to 
jam encryption down people's throats, but my latest experience with 
implementing CalDAV has left me with quite a cynical view. While people 
_have_ to follow standards, they don't. They make mistakes. And that's 
where obstacles to debugging annoy me. ReplyTo issue itself is perhaps 
easy to work-around, but it's the principle that matters.

I propose everywhere where there's a callback URL involved, the spec 
equally accept HTTP, but perhaps recommend a displaying a warning if 
used. Just like email and calendar apps do today. Demanding HTTPS from 
client software is just frustrating for us, server developers.

On 5/28/18 4:47 AM, Neil Jenkins wrote:
> On Fri, 25 May 2018, at 8:44 PM, Andri Möll wrote:
>> I'm all for strongly suggesting HTTPS for public Internet use, but 
>> during development I must say HTTPS is a pain in the ass. I, like a 
>> lot of other people, develop and test locally using either .local (if 
>> devices support zero conf) or a private domain in the likes of .dev 
>> or .test set up in the router.
>
> Following the standard is required if you wish to interoperate. For 
> when you are operating entirely within a closed system (develop + 
> test) you can of course ignore any requirements you like.
>
> Having said that, I'm personally ambivalent to whether it's a MUST or 
> a SHOULD, or a "make sure you really think about this". My view is any 
> decent service is only going to use HTTPS anyway, any shoddy service 
> probably won't read the RFC, and anyone doing some internal thing with 
> its own encryption layer will probably ignore it if they want to 
> anyway. /Shrug/.
>
> Neil.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Robert Stepanek <[email-masked]>
Date: Thu, 06 Sep 2018 04:18:13 -0400

On Wed, Sep 5, 2018, at 22:14, Andri Möll wrote: 
> This isn't about a shoddy service. This is about debugging 3rd party client software. 

> [...] 

> I propose everywhere where there's a callback URL involved, the spec equally accept HTTP, but perhaps recommend a displaying a warning if used. Just like email and calendar apps do today. Demanding HTTPS from client software is just frustrating for us, server developers. 

I've been reading IETF's best practice recommendations (https://tools.ietf.org/html/rfc3365) but the only thing I get out of that is "it depends".  
 
Personally, I'm leaning towards not restricting the URI scheme at all. The reason we have to label the "mailto:" URI with "imip" is only because a "mailto:" URI in itself doesn't allow client implementations to identify what payload to use in that email. I'd be equally fine to just use "imip" and "other" as keys in the "relatedTo" property, where the "other" URI can be an URI template using whatever scheme implementations will find useful. 
 
Would that be an improvement for clients? 
 
Cheers, 
Robert 

>>> I'm all for strongly suggesting HTTPS for public Internet use, but during development I must say HTTPS is a pain in the ass. I, like a lot of other people, develop and test locally using either .local (if devices support zero conf) or a private domain in the likes of .dev or .test set up in the router. 
>>  
>> Following the standard is required if you wish to interoperate. For when you are operating entirely within a closed system (develop + test) you can of course ignore any requirements you like. 
>>  
>> Having said that, I'm personally ambivalent to whether it's a MUST or a SHOULD, or a "make sure you really think about this". My view is any decent service is only going to use HTTPS anyway, any shoddy service probably won't read the RFC, and anyone doing some internal thing with its own encryption layer will probably ignore it if they want to anyway. *Shrug*. 
>>  
>> Neil. 
>>  
calsify mailing list

---

From: Marten Gajda <[email-masked]>
Date: Thu, 6 Sep 2018 22:38:53 +0200

Hi Andri,

just to be sure we're on the same page, this "ReplyTo an HTTPS address"
thing is not some kind of CalDAV extension or some kind of new protocol.
The CUA is not supposed to send some document to this address or
anything like that.

The sole purpose of an HTTPS ReplyTo address is to open it in a browser.
The URL should contain parameters which identify the event and the
attendee (if the user doesn't have an account on the server) and the
server would return an HTML page which prompts the user about the event
and his attendance status, giving him the options to accept or decline
the invite.

So this is really just a lightweight RSVP mechanism that doesn't build
upon ITIP.

I'd guess in 99+% of all cases this HTTPS URL is opened in a browser or
some kind of WebView. It's not something a CUA developer would have to
care about and server developers can just test their implementation with
available browser implementations.

Does that make sense?

Cheers,

Marten

Am 05.09.2018 um 22:14 schrieb Andri Möll:
> implementing CalDAV has left me with quite a cynical view. While
> people _have_ to follow standards, they don't. They make mistakes. And
> that's where obstacles to debugging annoy me. ReplyTo issue itself is
> perhaps easy to work-around, but it's the principle that matters.
>
>>> lot of other people, develop and test locally using either .local
>>> (if devices support zero conf) or a private domain in the likes of
>>> .dev or .test set up in the router.
>>
>> a SHOULD, or a "make sure you really think about this". My view is
>> any decent service is only going to use HTTPS anyway, any shoddy
>> service probably won't read the RFC, and anyone doing some internal
>> thing with its own encryption layer will probably ignore it if they
>> want to anyway. /Shrug/.
>>
>> Neil.
>>

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: Andri Möll <[email-masked]>
Date: Thu, 6 Sep 2018 22:00:11 +0000

Ah, thanks. I was indeed under the impression this is for automated 
responses. In that case Robert's proposal of not restricting URI schemes 
makes more sense.

On 9/6/18 8:18 AM, Robert Stepanek wrote:
> Personally, I'm leaning towards not restricting the URI scheme at all. 
> The reason we have to label the "mailto:" URI with "imip" is only 
> because a "mailto:" URI in itself doesn't allow client implementations 
> to identify what payload to use in that email. I'd be equally fine to 
> just use "imip" and "other" as keys in the "relatedTo" property, where 
> the "other" URI can be an URI template using whatever scheme 
> implementations will find useful.

I do have to ask, why key-value pairs? To be able to later differentiate 
between using the same protocol for two different purposes --- one that 
requires a human to interact and the other for automated responses?

If so, web URLs wouldn't need to be special-cased either and could live 
in the hypothetical "other" property. CUAs would pass them to the 
operating system to open just like they'd pass unknown URIs. Having 
"web" separately wouldn't contribute anything as an app would have to 
handle web URLs in "other" anyways.

On 9/6/18 8:38 PM, Marten Gajda wrote:
>
> Hi Andri,
>
> just to be sure we're on the same page, this "ReplyTo an HTTPS 
> address" thing is not some kind of CalDAV extension or some kind of 
> new protocol. The CUA is not supposed to send some document to this 
> address or anything like that.
>
> The sole purpose of an HTTPS ReplyTo address is to open it in a 
> browser. The URL should contain parameters which identify the event 
> and the attendee (if the user doesn't have an account on the server) 
> and the server would return an HTML page which prompts the user about 
> the event and his attendance status, giving him the options to accept 
> or decline the invite.
>
> I'd guess in 99+% of all cases this HTTPS URL is opened in a browser 
> or some kind of WebView. It's not something a CUA developer would have 
> to care about and server developers can just test their implementation 
> with available browser implementations.
>
> Does that make sense?
>
> Cheers,
>
> Marten
>
>> platforms') CalDAV quirks and managed to so by directing the apps to 
>> a development machine. Yet if CalDAV had demanded HTTPS to the 
>> server, I would've been hosed. You can't get a legit certificate for 
>> a local IP address nor do I have a Mac to install custom root 
>> certificates to an iPhone, for example. If that's even a thing 
>> anymore. Some client software have their own bundled roots. There it 
>> would've impossible to productively debug HTTPS-only services.
>>
>> people _have_ to follow standards, they don't. They make mistakes. 
>> And that's where obstacles to debugging annoy me. ReplyTo issue 
>> itself is perhaps easy to work-around, but it's the principle that 
>> matters.
>>
>> used. Just like email and calendar apps do today. Demanding HTTPS 
>> from client software is just frustrating for us, server developers.
>>
>>
>>> Having said that, I'm personally ambivalent to whether it's a MUST 
>>> or a SHOULD, or a "make sure you really think about this". My view 
>>> is any decent service is only going to use HTTPS anyway, any shoddy 
> email:[email-masked]

---

From: Robert Stepanek <[email-masked]>
Date: Fri, 07 Sep 2018 03:11:52 -0400

>> Personally, I'm leaning towards not restricting the URI scheme at all [...] 
> I do have to ask, why key-value pairs? To be able to later differentiate between using the same protocol for two different purposes --- one that requires a human to interact and the other for automated responses? 

Yes. AFAIK there's also efforts to implement iTIP over HTTP, so that would also be a case where the URI scheme alone isn't enough to differentiate interactive vs automated scheduling responses. 
 
> If so, web URLs wouldn't need to be special-cased either and could live in the hypothetical "other" property. CUAs would pass them to the operating system to open just like they'd pass unknown URIs. Having "web" separately wouldn't contribute anything as an app would have to handle web URLs in "other" anyways. 

That was my idea, but it seems like I didn't communicate it correctly :) 
 
Cheers, 
Robert