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 remove the need for parsing the message of the invalidContact error. This seems cleaner to me.
I believe there will always be cases where a general purpose ACME client will attempt to use a feature unsupported by a given server and will have to react accordingly. Rather than try to preempt all of these cases by supplying metadata on all of the available options I'd favour refining the errors the server returns and promoting flexibility in handling them client side. On Thu, Mar 23, 2017 at 2:06 PM, Zach Shepherd <[email protected]> wrote: > 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 of this information to in an > account creation request. Some of the time, this will result in an error > because the ACME server does not support tel. > > When the ACME client receives this error, it could: > 1. Display it to the user and ask the user to adjust their input > accordingly. (A poor user experience.) > 2. Attempt to parse to the error message to confirm that the problem was > the tel. (Hacky.) > 3. Assume that the problem was the tel and retry without that. (Very > hacky.) > > A new ACME server could come along that requires at least one tel or that > doesn't support mailto. As a result, ACME clients may chose to attempt #2 > and/or #3 before falling back to #1. > > This means that ACME clients have one of six different behaviors (#1, #2, > #3, #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 > falling back to #1), some of which add a non-trivial amount of complexity > to attempt to parse error messages (yuck.) and some of which end up pushing > the complexity onto the end-user in end anyways. (Or worse, ACME clients > wind up with hard-coded assumptions based on a specific ACME server > implementation and become less portable.) > > Providing information about the supported contact schemes in a machine > readable format (e.g., in response to a GET requests on the server's > new-account URI) does add work for ACME server implementors, but not so > much that it's worth complicating the end-user experience. > > Regards, > Zach > > ------------------------------ > *From:* Daniel McCarney <[email protected]> > *Sent:* Wednesday, March 22, 2017 10:43 AM > *To:* Zach Shepherd > *Cc:* [email protected] > *Subject:* Re: [Acme] Allowing clients to understand the account creation > functionality supported by a server > > Hi Zach, > > > It is undesirable that a client can only determine the supported schemes > for contact URLs by attempting to submit an unsupported URL. This makes it > difficult to implement a general-purpose client which can work with a > variety of servers which might each support a different set of contact > schemes. > > I feel your pain, but I'm hesitant to see more metadata/complexity put > into the /directory (I think the "meta" field of the directory resource > would be the best place if anywhere). My gut says it will be unlikely many > servers will allow contact URLs outside of "mailto:"; and "tel:" and it > seems reasonably easy to handle the unsupported contact type error. For the > account fields we'd be adding complexity to simplify UI and I'm not > convinced yet its justified. > > Another note: If consensus is that we need a machine-readable way for > clients to know ahead of time what contact methods & account fields a > server supports we should also give the same consideration to identifier > types for Section 7.4.1's Pre-Authorization mechanism. A client may want to > know what types of identifiers a server would pre-authorize. > > On Wed, Mar 22, 2017 at 1:13 AM, Zach Shepherd <[email protected]> > wrote: > >> The following feedback is based on 8010a31 (current HEAD of master). >> >> Section 7.3, Account Creation, states "The server SHOULD validate that >> the contact URLs in the “contact” field are valid and supported by the >> server. If the client provides the server with an invalid or unsupported >> contact URL, then the server MUST return an error of type “invalidContact”, >> with a description describing the error and what types of contact URL the >> server considers acceptable." >> >> It is undesirable that a client can only determine the supported schemes >> for contact URLs by attempting to submit an unsupported URL. This makes it >> difficult to implement a general-purpose client which can work with a >> variety of servers which might each support a different set of contact >> schemes. >> >> I would propose including information about the supported contact schemes >> in a machine readable format as a part of some GET request. >> >> >> Section 7.3, Account Creation, also states "A client creates a new >> account with the server by sending a POST request to the server’s >> new-account URI. The body of the request is a stub account object >> containing the “contact” field and optionally the “terms-of-service-agreed” >> field. ... The server MUST ignore any values provided in the “orders” >> fields in account bodies sent by the client, as well as any other fields >> that it does not recognize. If new fields are specified in the future, the >> specification of those fields MUST describe whether they can be provided by >> the client." >> >> Similarly, it would be beneficial for a client to be able to determine >> the set of fields that a server does recognize so that it does not prompt >> the user for information which the server will not make use of. >> >> I would propose including information about the fields which may be >> specified as a part of account creation in a machine readable format as a >> part of some GET request. >> >> >> Together, these proposals could be addressed by responding to GET >> requests on the server's new-account URI with an object describing the >> client-specifiable account creation fields and applicable restrictions on >> each, such as the supported schemes for contacts URLs. >> >> Regards, >> Zach Shepherd >> >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=mLXl-Tt4EwYbR1MBiFQQ0WZ5XFbdy4TsA2LeBwzJ7eE&s=Iwaw66ccf6rwdCNvFQfF5apZ1WRKaNmkYwyfq954enk&e=> >> >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
