On Thu, Jul 28, 2016 at 7:14 PM, Roland Shoemaker <[email protected]> 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 > > > On Jul 28, 2016, 3:25 PM -0700, Richard Barnes <[email protected]>, wrote: > > 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 protected]> > wrote: > >> 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 protected]>, wrote: >> >> Hi Richard >> >> On Thu, Jul 28, 2016 at 2:42 PM, Richard Barnes <[email protected]> wrote: >> >>> Roland filed an issue proposing removal of any URIs other than "mailto: >>> ". >>> >>> https://github.com/ietf-wg-acme/acme/issues/159 >>> >>> 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. >>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> >>> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
