Subject: [Acme] Section 6.1.2 - "Registration Objects" Drift

From: Daniel McCarney <[email-masked]>
Date: Wed, 21 Sep 2016 13:57:12 -0400

Hi again folks,

Section 6.1.2 ("Registration Objects") of the current draft[0] spends 5
sentences describing the "applications" field of a registration object. I
think there was some drift here and parts still refer to "authorizations"
and the accompanying example object was incorrect (providing 1 application
URI instead of an array with the described fields).

I took a pass at trying to update this section to be consistent in its
terms and examples and a little bit simpler overall. I would appreciate
feedback on my pull request [1] from the list.

Thanks!

- Daniel/cpu

[0] -
https://github.com/ietf-wg-acme/acme/blob/83e2f7985f5921a4ac30b7446dbb9c1d347d69ec/draft-ietf-acme-acme.md#registration-objects

[1] -  https://github.com/ietf-wg-acme/acme/pull/192

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 23 Sep 2016 15:30:38 -0700

On 09/21/2016 10:57 AM, Daniel McCarney wrote:
> Section 6.1.2 ("Registration Objects") of the current draft[0] spends
> 5 sentences describing the "applications" field of a registration
> object. I think there was some drift here and parts still refer to
> "authorizations" and the accompanying example object was incorrect
> (providing 1 application URI instead of an array with the described
> fields).
The intent here was to have a single URL that would return a JSON list
of application URLs. Because the list can get quite large, it could be
broken into pages. It's relatively expensive to enumerate the whole list
of pages in advance, and prone to errors when the list changes during
iteration, so we only supported a notion of getting the first page, plus
a "next" link. Here's an example (with very short pages):

GET /acme/1234/applications
200 OK
Link: href="/acme/1234/applications?cursor=888", rel="next"
Content-Type: application/json

[
 "https://example.com/acme/applications/4444",
 "https://example.com/acme/applications/8888"
]

GET /acme/1234/applications?cursor=8888
200 OK
Link: href="/acme/1234/applications?cursor=9999", rel="next"
Content-Type: application/json

[
 "https://example.com/acme/applications/9000",
 "https://example.com/acme/applications/9999"
]

GET /acme/1234/applications?cursor=9999
200 OK
Content-Type: application/json

[
 "https://example.com/acme/applications/10000"
]

I think breaking out the description of these "application list" objects
into their own section makes sense, but I don't think the semantic
changes in this PR are ideal.

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 28 Sep 2016 17:14:22 -0400

Thanks for the feedback Jacob!

What you described makes sense - I've restored the original semantics and
broke
the "applications list" out into its own section.

The PR is updated if you'd like to give it another read. Hopefully its both
accurate to the original semantics and easier to read/understand :-)

- cpu