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 <[email protected]> wrote: > 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
