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