- Start Date: (fill me in with today's date, DD-MM-YYYY)
- RFC(request for comments) PR: [repository name/rfcs#pr number](https://gitee.com/openharmony/repositroy-name/pulls/xxxx)
- Issue: [repository name/issue number](https://gitee.com/openharmony/repository-name/issues/xxxxxx)
# (RFC title goes here)

## Summary

> One paragraph explanation of the change.

## Motivation

> Why are we doing this? What use scenario does it support? What is the expected outcome?

## Design Detail

> Explain the design in enough detail for somebody
familiar with the infrastructure to understand. This should get into specifics and corner-cases,
and include examples of how the service is used. Any new terminology should be
defined here.

## Drawbacks

> Why should we *not* do this? Please consider the impact on users,
on the integration of this change with other existing and planned features etc.

> There are tradeoffs to choosing any path, please attempt to identify them here.

## Rationale and 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

Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:

> How other services / infrastructures in the same domain have solved this problem.

> 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 organisations, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting whether they are brand new or if it is an adaptation from other services.

## 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 stabilisation?

> 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?