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 <r...@ipv.sx>, 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 <rol...@letsencrypt.org > (mailto:rol...@letsencrypt.org)> 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 <ted.i...@gmail.com > > (mailto:ted.i...@gmail.com)>, wrote: > > > Hi Richard > > > > > > On Thu, Jul 28, 2016 at 2:42 PM, Richard Barnes <r...@ipv.sx > > > (mailto:r...@ipv.sx)> 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 > > > > Acme@ietf.org (mailto:Acme@ietf.org) > > > > https://www.ietf.org/mailman/listinfo/acme > > > > > > > > > > _______________________________________________ > > > Acme mailing list > > > Acme@ietf.org (mailto:Acme@ietf.org) > > > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
