Draft: draft-ietf-acme-acme

Commentary: In the " applications " field of the registration resource is described in great detail . This is confusing for two reasons : the text and the example registration object are still using the " authorization " term that applications replace . text is written as if the applications should be directly embedded in the registration object returned . This PR addresses both issues by describing the " applications " field as an array of application URIs that the client can fetch . The example " registration " object is updated accordingly . The note indicating a server SHOULD include pending applications and SHOULD NOT include invalid applications remains as - is . The note indicating a server MAY return an incomplete list is removed - it is more complicated and with only URIs being returned , likely an unneeded optimization . Finally , in there are three fields that must be ignored by the server in a registration body : key , authorizations and certificates . This should be " key " and " applications " and is updated accordingly . 
 feedback addressed , and conflicts w/ master resolved . Thanks for the : eyes : !
Paragraph (version A):
A URI from which a list of authorizations submitted by this
account can be fetched via a GET request.  The result of the GET
request MUST be a JSON object whose "applications" field is an
array of strings, where each string is the URI of an authorization
belonging to this registration.  The server SHOULD include pending
applications, and SHOULD NOT include applications that are
invalid.  The server MAY return an incomplete list, along with a
Link header with link relation "next" indicating a URL to retrieve
further entries.
Paragraph (version B):
A URI from which an array of URIs for application objects
submitted by this account can be fetched via a GET request.
Paragraph (version B):
Each registration object includes an applications URI from which a
list of applications created by the registration can be fetched via
GET request.  The result of the GET request MUST be a JSON object
whose "applications" field is an array of URIs, each identifying an
applications belonging to the registration.  The server SHOULD
include pending applications, and SHOULD NOT include applications
that are invalid in the array of URIs.  The server MAY return an
incomplete list, along with a Link header with link relation "next"
indicating a URL to retrieve further entries.
Paragraph (version A):
The server MUST ignore any values provided in the "key",
"authorizations", and "certificates" fields in registration 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 may be
provided by the client.
Paragraph (version B):
The server MUST ignore any values provided in the "key", and
"applications" fields in registration 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 may be provided by the client.
Paragraph (version A):
If the client wishes to update this information in the future, it
sends a POST request with updated information to the registration
URI.  The server MUST ignore any updates to the "key",
"authorizations, or "certificates" fields, and MUST verify that the
request is signed with the private key corresponding to the "key"
field of the request before updating the registration.
Paragraph (version B):
If the client wishes to update this information in the future, it
sends a POST request with updated information to the registration
URI.  The server MUST ignore any updates to the "key", or
"applications" fields or any other fields it does not recognize.  The
server MUST verify that the request is signed with the private key
corresponding to the "key" field of the request before updating the
registration.