Jakarta RPC Progress Review (Alternatively Plan Review for Jakarta RPC 1.0)

The Creation Review for RPC concluded on the 19th of January 2022. As per the [Jakarta EE Specification Process](https://www.eclipse.org/projects/efsp/#efsp-version-lifecycle), Jakarta RPC is due a Progress Review.

The Specification Committee has received a request from the Jakarta EE Platform team for a progress report.

Please reach out to me or comment on this issue if anything is not clear and as your assigned mentor I will see what I can do to help.

Below is the checklist we will be using to review.

1. Spec PR for Plan / Proposal

* [ ] There is no new material that wasn't previously provided that would impact the existing Specification "work in progress" page layout.

2. _index.md

* [ ] If there are milestones previously approved and/or documented on the Specification page, but now out of date, or not feasible (missed checkpoints or other milestones), there must be a proposed PR to refresh the previously approved plan material.
* [ ] The progress review should demonstrate the agreed plan is still correct and accurate. If it is not, the Progress Review is an opportunity to revise the plan as needed.
* [ ] Mentor to confirm (via consultation with committer team) the scope is correct. If it has been revised, those changes should be summarized. Regardless, the committer team is responsible for providing any statements or documentation describing progress for the progress review materials.

* [ ] The mentor may wish to review the Plan Review Ballot checklist to confirm all items are captured.
* [ ] If checkpoint or scope material is derived from issues or epic issues, the mentor may wish to request the committer team provide a summary statement of the specific progress against the issue or issues.
* [ ] The committer team should provide an overall assessment that confirms they are "on track" or produces a plan revision that reflects the evolution since the last ballot.
* [ ] The mentor should focus material for this review on progress of this specification revision and not the progress or changes associated with higher level projects (i.e. it is probably insufficient to say "schedule changed in Platform Release Plan so we're changing too"). Scope changes that have been imposed on this specification may certainly be noted and may be a source for plan revisions.
* [ ] Any changes or additional requirements, resource needs (e.g. CI/CD resources), feature changes, etc. should be reflected in the specification plan revision. If there are no changes the committer team should be able to demonstrate that they are progressing within the original plan that is already approved.

3. Proposed Spec PDF (Optional)

* [ ] Correct spec title, clearly marked preliminary
* [ ] Correct Eclipse copyright line
* [ ] Must indicate DRAFT or SNAPSHOT
* [ ] Correct Logo

4. Proposed Spec HTML (Optional)

* [ ] Same as PDF

5. TCK

* [ ] Some statement or evidence of TCK development progress and accomplishment from previous review

Start with the specification repository's _index.md and the Jakarta EE Specification Process lifecycle guidance. Review the proposed Spec PR, optional PDF and HTML materials, and TCK progress evidence against the checklist. Done means the plan and progress statements are current, any needed revisions are proposed, and the review materials cover the required scope.

Written by the indexing model from the issue text.