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

From: Andri Möll <[email-masked]>
Date: Fri, 25 May 2018 10:44:33 +0000

Hey,

I'd like to challenge the HTTPS-only requirement of ReplyTo and possibly 
other future properties in favor of a better development experience.

On 05/25/2018 08:26 AM, Robert Stepanek wrote:
> *replyTo*: the HTTP path template for the replyTo `web` property must 
> use HTTPS.

Neil Jenkins:
>>
>> *Section 4.4.4. replyTo*
>>
>> Method “web”: It’s 2018, can we ditch support for plain, insecure 
>> “http”, and only support the secure version? A JSCalendar object with 
>> an insecure replyTo address is invalid and MUST be rejected.
>>
>
> Seems reasonable to me, although in practice I wonder how many 
> implementations will actually reject the whole object because of an 
> http: /replyTo/ property.

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. With HTTPS, one would have to migrate to a 
public [paid] domain; start managing and distributing certificates among 
team members; give up using .local in networks one doesn't control and 
with devices you can't change /etc/hosts on; etc.

I'd argue HTTPS-only suggested through "SHOULD" combined with shaming of 
people using HTTP in the public net suffices. People occasionally do 
weird things that make HTTPS redundant (proxying HTTP directly to the 
web server over SSH). Let them. I don't think it's wise to corner 
oneself in a spec like this.

Andri

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 28 May 2018 00:47:15 -0400

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.