Subject: [Acme] Contact URIs

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Jul 2016 17:42:21 -0400

Roland filed an issue proposing removal of any URIs other than "mailto:".

https://github.com/ietf-wg-acme/acme/issues/159

I really strongly disagree with this.  At the level of this protocol, we
should allow clients to specify whatever types of contact they want, as
long as it can be specified in a URI.

I would be willing to have some text that explicitly allows the server to
filter the contact list, though, so that it's clear to the client what the
server does and doesn't support.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 Jul 2016 15:16:44 -0700

Hi Richard

On Thu, Jul 28, 2016 at 2:42 PM, Richard Barnes <[email-masked]> wrote:

> I think there is another way to look at the issue.  Rather than focusing
on removing PSTN, you could say that he is requesting that mailto: be
universally supported, where other URI forms would be at the discretion of
the CA.

Put that way, I think it's worth consideration.  If there is a single
contact method that ACME requires, mailto makes sense.

> long as it can be specified in a URI.
A data URI could have instructions on where to show up as a series of
navigational cues, so "can be specified in a URI" may not be enough.

 Ted

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

---

From: Roland Shoemaker <[email-masked]>
Date: Thu, 28 Jul 2016 15:21:59 -0700

I agree with Ted that generic URI support should be documented but that mailto should be the only one explicitly referred to.

This was the intention of the original ticket I filled, although maybe not as coherently.

On Jul 28, 2016, 3:17 PM -0700, Ted Hardie <[email-masked]>, wrote:
> Hi Richard
>
> On Thu, Jul 28, 2016 at 2:42 PM, Richard Barnes <[email-masked] (mailto:[email-masked])> wrote:
> I think there is another way to look at the issue. Rather than focusing on removing PSTN, you could say that he is requesting that mailto: be universally supported, where other URI forms would be at the discretion of the CA.
>
> Put that way, I think it's worth consideration. If there is a single contact method that ACME requires, mailto makes sense.
> > I really strongly disagree with this. At the level of this protocol, we should allow clients to specify whatever types of contact they want, as long as it can be specified in a URI.
> >
>
> A data URI could have instructions on where to show up as a series of navigational cues, so "can be specified in a URI" may not be enough.
>
> Ted
>
> > I would be willing to have some text that explicitly allows the server to filter the contact list, though, so that it's clear to the client what the server does and doesn't support.
> >
> > [email-masked] (mailto:[email-masked])

---

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Jul 2016 18:25:24 -0400

So how about we add something like this:

- Servers SHOULD only allow contact types they know how to handle
- ... MUST filter unsupported contacts;
- ... MUST support "mailto:"

Roland: When you say "explicitly referred to", do you mean in the
examples?  I would prefer to keep a non-mailto example there, if we're
clear that the server can reject it.

On Thu, Jul 28, 2016 at 6:21 PM, Roland Shoemaker <[email-masked]>
wrote:

> I agree with Ted that generic URI support should be documented but that
> mailto should be the only one explicitly referred to.
>

---

From: Roland Shoemaker <[email-masked]>
Date: Thu, 28 Jul 2016 16:14:14 -0700

That sounds good, adding this more specific language about how the server should treat non-mailto URIs would make the tel examples make more sense to me.

When you say 'filter' unsupported contacts what do you mean? It seems like erroring out seems like it would be more prudent.

On Jul 28, 2016, 3:25 PM -0700, Richard Barnes <[email-masked]>, wrote:
> Roland: When you say "explicitly referred to", do you mean in the examples? I would prefer to keep a non-mailto example there, if we're clear that the server can reject it.
>
>
> On Thu, Jul 28, 2016 at 6:21 PM, Roland Shoemaker <[email-masked] (mailto:[email-masked])> wrote:
> > On Jul 28, 2016, 3:17 PM -0700, Ted Hardie <[email-masked] (mailto:[email-masked])>, wrote:
> > > Hi Richard
> > >

---

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Jul 2016 19:41:18 -0400

On Thu, Jul 28, 2016 at 7:14 PM, Roland Shoemaker <[email-masked]>
wrote:

> That sounds good, adding this more specific language about how the server
> should treat non-mailto URIs would make the tel examples make more sense to
> me.
>
> When you say 'filter' unsupported contacts what do you mean? It seems like
> erroring out seems like it would be more prudent.
>

I mean that the "contact" list in the returned registration object would be
a subset of the list in the client's POST.

I don't have super strong feelings about error vs. filter, but have a
slight preference for filtering.  We went the hard-fail way with new-cert
(now new-app), but in this case, the client can fix things by updating the
registration, so it seems like less of a big deal.

--Richard