>From my perspective, the UX from not having this feature is pretty awful.
And for clients to try to make the UX not awful, they'd have to add quite a
bit of complexity.
I'd much rather a must with a bit of extra information in the meta
directory.
___
> Dumping some of this info in `directory.meta` doesn't really seem that
tragic to me. It's not that much information, and could avoid some errors.
Do you feel strongly enough about it to make it a MUST? If it isn't a MUST
it seems like we'd be back in the situation that Zach wants to avoid.
On
Dumping some of this info in `directory.meta` doesn't really seem that
tragic to me. It's not that much information, and could avoid some errors.
I would note, however, that we could also do this in an extension, rather
than in the main spec.
On Tue, Mar 28, 2017 at 6:04 PM, Daniel McCarney
I still think this is the wrong layer to solve this problem. If the crux of
the matter is that `urn:ietf:params:acme:error:invalidContact` isn't
sufficient to distinguish between invalid vs unsupported without parsing we
could add a `urn:ietf:params:acme:error:unsupportedContact` error type and
Let's consider a simple world where all ACME servers support mailto and some
ACME servers support tel.
To create an account, the user provides the necessary information to their AMCE
client: one or more email addresses and zero or more phone numbers. The ACME
client then attempts to supply all
