Update RFC for extend chaincode lifecycle API to query all approved c…

…haincodes

- Fix the format
- Update some information

Signed-off-by: Tatsuya Sato <tatsuya.sato.so@hitachi.com>

text/0000-fabric-extend-chaincode-lifecycle-api-to-query-all-aproved-chaincode.md

@@ -1,6 +1,6 @@
 ---
 layout: default
-title: RFC Template
+title: Extend chaincode lifecycle API to query all approved chaincodes
 nav_order: 3
 ---
 
@@ -11,7 +11,9 @@ nav_order: 3
 - Fabric Issue: (leave this empty)
 
 # Summary
-[summary]: Extend chaincode lifecycle API to query all approved chaincodes
+[summary]: #summary
+
+## Extend chaincode lifecycle API to query all approved chaincodes
 
 Currently, Fabric peer CLI 'queryapproved' could query the details of an approved chaincode definitions, and this CLI requires a mandatory chaincode name parameter to query a specific chaincode definitions; however, in some cases we expect to query out all approved chaincode definitions.
 
@@ -21,13 +23,13 @@ The following shows a basic design of this extension.
 
 - There is no new command is involved.
 - Command 'queryapproved' will be extended to support this function:
-  -- make parameter (n|-name <chaincode>) optional
-  -- if parameter (n|-name <chaincode>) is provided, keep current command behavior
-  -- if parameter (n|-name <chaincode>) is not provided, query the details of all approved chaincode, plus additional chaincode name in details output.
+  - make parameter (-n|--name [chaincode_name]) optional
+  - if parameter (-n|--name [chaincode_name]) is provided, keep current command behavior
+  - if parameter (-n|--name [chaincode_name]) is not provided, query the details of all approved chaincode, plus additional chaincode name in details output.
 
-* The example of query all approved chaincodes with JSON output format: *
+*The example of query all approved chaincodes with JSON output format:*
 ```
-$ peer lifecycle chaincode queryapproved --channelID <channelname> -o orderer.example.com:7050 --peerAddresses peer0.org1.example.com:7051 --output json
+$ peer lifecycle chaincode queryapproved --channelID <channelname> --peerAddresses peer0.org1.example.com:7051 --output json
 {
 	"chaincode_definitions": [
 		{
@@ -88,111 +90,25 @@ $ peer lifecycle chaincode queryapproved --channelID <channelname> -o orderer.ex
 # Motivation
 [motivation]: #motivation
 
-Why are we doing this? What use cases does it support? What is the expected
-outcome?
+In some cases we expect to query out all approved chaincode definitions.
 
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
-Explain the proposal as if it was already included in Fabric and you were
-teaching it to another Fabric developer. That generally means:
-
-- Introducing new named concepts.
-- Explaining the feature largely in terms of examples.
-- Explaining how Fabric programmers should *think* about the feature, and how
-  it should impact the way they use fabric. It should explain the impact as
-  concretely as possible.
-- If applicable, provide sample error messages, deprecation warnings, or
-  migration guidance.
-- If applicable, describe the differences between teaching this to established
-  and new Fabric developers.
-- If applicable, describe any changes that may affect the security of
-  communications or administration.
-
-For implementation-oriented RFCs (e.g. for validator internals), this section
-should focus on how contributors should think about the change, and give
-examples of its concrete impact. For policy RFCs, this section should provide
-an example-driven introduction to the policy, and explain its impact in
-concrete terms.
+The original 'queryapproved' implementation can be found by referring to a series of PRs, including this [PR](https://github.com/hyperledger/fabric-protos/pull/25).
 
 # Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
 
-This is the technical portion of the RFC. Explain the design in sufficient
-detail that:
-
-- Its interaction with other features is clear.
-- It is reasonably clear how the feature would be implemented.
-- Corner cases are dissected by example.
-
-The section should return to the examples given in the previous section, and
-explain more fully how the detailed proposal makes those examples work.
-
-# Drawbacks
-[drawbacks]: #drawbacks
-
-Why should we *not* do this? Are there any risks that must be considered along with
-this rfc. 
-
-# Rationale and alternatives
-[alternatives]: #alternatives
-
-- Why is this design the best in the space of possible designs?
-- What other designs have been considered and what is the rationale for not
-  choosing them?
-- What is the impact of not doing this?
-
-# Prior art
-[prior-art]: #prior-art
-
-Discuss prior art, both the good and the bad, in relation to this proposal.
-A few examples of what this can include are:
-
-- For consensus, global state, transaction processors, and smart contracts
-  implementation proposals: Does this feature exists in other distributed
-  ledgers and what experience have their communities had?
-- For community proposals: Is this done by some other community and what were
-  their experiences with it?
-- For other teams: What lessons can we learn from what other communities have
-  done here?
-- Papers: Are there any published papers or great posts that discuss this? If
-  you have some relevant papers to refer to, this can serve as a more detailed
-  theoretical background.
-
-This section is intended to encourage you as an author to think about the
-lessons from other distributed ledgers, provide readers of your RFC with
-a fuller picture.  If there is no prior art, that is fine - your ideas are
-interesting to us whether they are brand new or if it is an adaptation.
-
-Note that while precedent set by other distributed ledgers is some motivation,
-it does not on its own motivate an RFC.  Please also take into consideration
-that Fabric sometimes intentionally diverges from common distributed
-ledger/blockchain features.
+The command reference of the original 'queryapproved' is [here](https://hyperledger-fabric.readthedocs.io/en/latest/commands/peerlifecycle.html#peer-lifecycle-chaincode-queryapproved).
 
 # Testing
 [testing]: #testing
 
-- What kinds of test development and execution will be required in order
-to validate this proposal, beyond the usual mandatory unit tests?
-- List integration test scenarios which will outline correctness of proposed functionality.
+- Enhance existing unit and integration tests on 'queryapproved' command.
 
 # Dependencies
 [dependencies]: #dependencies
 
-- Describe all dependencies that this proposal might have on other RFCs, known JIRA issues,
-Hyperledger Fabric components.  Dependencies upon RFCs or issues should be recorded as 
-links in the proposals issue itself.
-
-- List down related RFCs proposals that depend upon current RFC, and likewise make sure 
-they are also linked to this RFC.
-
-# Unresolved questions
-[unresolved]: #unresolved-questions
-
-- What parts of the design do you expect to resolve through the RFC process
-  before this gets merged?
-- What parts of the design do you expect to resolve through the implementation
-  of this feature before stabilization?
-- What related issues do you consider out of scope for this RFC that could be
-  addressed in the future independently of the solution that comes out of this
-  RFC?
+- fabric-protos
+	- This feature needs to extend lifecycle protos (e.g., Adding 'QueryApprovedChaincodeResults').