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
