Summarizing for reference - NOT a complete list of feedback but the ones I think I can tackle in the next rev
[x] Shift to more formal language. For example, explain how user can communicate an intent to setup a redirect URL rather than give examples of how that might happen with a Web UX.
[x] Add that the source server issuing an OAuth token MUST associate it with a user account and only that account.
[x] Add more detail on how to do/handle rate limiting. what specific HTTP response code, and what the party being told to rate limit should do next.
[x] Explain better that the phases are NOT normative, they're to understand an important flow that is enabled by the tools specified, -- and that no state need be communicated between servers around phases.
[x] Explain 3.2.4 "Content may be filtered at the source" better. This can be done by a source server anyway, it doesn't depend on other FEPs, it does depend on user communicating intent.
[x] Section 3.4 "feels like a thread... replace with more prescriptive" ? I can fix this - it is intended to be an introduction to concepts that are more prescriptively defined later - but I should explain that and label it as non-normative
[x] Fix the reference to "account name" in 6.1 - not a well-defined AP term
[x] Explain the first reference to a "migration outbox" better -the reader shouldn't have to read ahead to 6.7.1 to understand the refrence in 6.1. Explain that the destination server SHOULD copy data from the migration outbox if available rather than the regular outbox.
[x] Instead of group membership section, explain a general policy and template for new activity types or purposed collections
[x] “A destination server should attempt to provide appropriate GUI affordances to be able to tell whether to keep or rewrite the Actor property. For example, an account page with text like “Move my content from old account” would indicate a wish to update the actor ID.” - confused
[x] the example of translating type is complicated… i feel like this only works if the “original” version of any doctored object is stored (somewhere?), because what if you migrate again, do you send the original or your translated version to the 3rd server?
[x] 6.8 doesn't explain how the destination server is supposed to know what view permissions are. Also considerations for things that have a 'to' list but are NOT public?
[x] 7.2.3 the 'redirect_ap_obj' parameter - require escaping - explain how it's not an information leaking problem - explain the benefit of this approach that it allows AP-unaware browsers to be redirected
Summarizing for reference - NOT a complete list of feedback but the ones I think I can tackle in the next rev