From 82a89ac33aa071bf5faf99c6ce3df6ff46ff786a Mon Sep 17 00:00:00 2001 From: Ajay Date: Fri, 10 Apr 2026 21:00:48 +0530 Subject: [PATCH] docs: proofread and fix documentation issues --- CONTRIBUTION.md | 20 +++++++++---------- GOVERNANCE.md | 10 +++++----- MAINTAINERS.md | 6 +++--- README.md | 10 +++++----- ...KN-001-Layering-Network-Policy-Draft-01.md | 4 ++-- ...-002-Payments-On-Beckn-Enabled-Networks.md | 2 +- ...3-Beckn-Protocol-Communication-Draft-01.md | 4 ++-- ...dministration-On-Beckn-Enabled-Networks.md | 4 ++-- docs/BECKN-005-Error-Codes-Draft-01.md | 2 +- ...006-Signing-Beckn-APIs-In-HTTP-Draft-01.md | 2 +- docs/BECKN-009-Tags-the-Edge-of-Beckn.md | 8 ++++---- docs/README.md | 2 +- 12 files changed, 37 insertions(+), 37 deletions(-) diff --git a/CONTRIBUTION.md b/CONTRIBUTION.md index 00c7a478..95fa8e8d 100644 --- a/CONTRIBUTION.md +++ b/CONTRIBUTION.md @@ -40,7 +40,7 @@ This document is intended for the following audience. # Context -Beckn protocol specification exists as a set of public repositories on Github at https://github.com/beckn. Like all version controlled open-source repositories, there are guidelines that must be followed; design principles to be considered in order to propose changes to the files present in these repositories. These pull requests will then be reviewed by the maintainers of the repository and subsequently merged with the main / master branch of that repository. The governing body and repository maintainer of the beckn protocol specification is the **Core Working Group**. +Beckn protocol specification exists as a set of public repositories on GitHub at https://github.com/beckn. Like all version controlled open-source repositories, there are guidelines that must be followed; design principles to be considered in order to propose changes to the files present in these repositories. These pull requests will then be reviewed by the maintainers of the repository and subsequently merged with the main / master branch of that repository. The governing body and repository maintainer of the beckn protocol specification is the **Core Working Group**. # Abstract @@ -53,7 +53,7 @@ The evolution of beckn protocol specification should be use-case driven. The wor 1. **Git:** A decentralized version control software -2. **Github:** An online platform for managing shared repositories via git +2. **GitHub:** An online platform for managing shared repositories via git 3. **Pull Request:** A request to merge a change to an existing version of the repository 4. **Core Working Group:** Current maintainer and governing authority of the specification @@ -79,7 +79,7 @@ Contributing to the specification involves active participation by the contribut 1. Knowledge of the specification -2. Initiating healthy discussions on Github and Slack +2. Initiating healthy discussions on GitHub and Slack 3. Helping other community members with Issues 4. Providing sufficient documentation and in-depth analysis 5. Following a code of conduct in the discussion forums @@ -100,9 +100,9 @@ All contributors are expected to review the specification before submitting a pr Joining the open community on Discord is a simple process. Click [here]( https://bit.ly/bocWebInvite) to join the developer community on Discord. This is useful to have quick real-time interactions with the members of the community. -## 3. Initiate / participate in discussion threads on Github +## 3. Initiate / participate in discussion threads on GitHub -Before proposing a change to the specification, visit the discussion threads on Github [here](https://github.com/beckn/protocol-specifications/discussions) +Before proposing a change to the specification, visit the discussion threads on GitHub [here](https://github.com/beckn/protocol-specifications/discussions) ## 4. Subscribe to existing Issues or Pull Requests @@ -150,7 +150,7 @@ For each change in the specification we should always consider the following: **GitHub** is the medium of record for all spec designs, use cases, and so on. -All the specification related repositories are present on the official beckn protocol Github account [here](https://github.com/beckn). +All the specification related repositories are present on the official beckn protocol GitHub account [here](https://github.com/beckn). ## Sources of Truth @@ -182,7 +182,7 @@ New features should be done in feature branches/forks which, upon approval, will ## Raising an Issue in the Specification -Any change to the specification must begin with the creation of a Github Issue. The process for raising an issue on GitHub is detailed [here](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue). +Any change to the specification must begin with the creation of a GitHub Issue. The process for raising an issue on GitHub is detailed [here](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue). ## Creating a Pull Request @@ -213,8 +213,8 @@ The name of any new property in the core schema must be namespaced using the bel 1. **The dot slash ( ./ )** : This symbol in the context of core specification represents a non-standard property in the core schema. If this property is being developed by a network, all platforms must be able to recognize that this attribute is currently not part of the core specification and use / ignore it appropriately. 2. **namespace-id **: This is a unique id linked to a feature being submitted for inclusion in the specification by a unique entity. The format of the ID varies with the proposer of the feature. - 1. **For Individuals** : Individuals submitting new features must namespace the property with their **Github username**.For example, if Alice is a developer (_username : @alice-dev_) wants to add a feature called `"direction"` in core schema, she must submit her proposal with the new property **"./@alice-dev.direction.proposed" - 2. For Organizations: Organizations submitting new features must namespace the property with their Github orgname. For example, if Beckn Foundation (username : @beckn-foundation) wants to add a feature called “speed” in core schema, she must submit her proposal with the new property "./@beckn-foundation.speed.proposed" + 1. **For Individuals** : Individuals submitting new features must namespace the property with their **GitHub username**.For example, if Alice is a developer (_username : @alice-dev_) wants to add a feature called `"direction"` in core schema, she must submit her proposal with the new property **"./@alice-dev.direction.proposed" + 2. For Organizations: Organizations submitting new features must namespace the property with their GitHub orgname. For example, if Beckn Foundation (username : @beckn-foundation) wants to add a feature called “speed” in core schema, she must submit her proposal with the new property "./@beckn-foundation.speed.proposed" 3. feature-name : This is the name of the feature. While creating the feature-name, proposers are recommended to use the following guidelines before submitting the proposal. Please note that these are more like guidelines than rules. - The English language must be used to propose any new features. - Standard programming jargon can be used as long as it is widely accepted by the developer community. For example "const" is an acceptable keyword. @@ -228,7 +228,7 @@ New features under discussion should be identified by the prefixed **“./”** ## Identifying a new feature in Issues -New features in Github Issues will be **labeled** with the **feature-stage** label and will be initially labelled as **proposed, draft, recommended, required or not-recommended**. When the proposal is considered sufficiently stable for pilot implementation, it will be labeled **recommended**. If during the development of a draft feature, it is determined that the feature needs to change in a way that may break existing draft implementations, the “draft” feature-stage name itself may be versioned with a version suffix. e.g. draft-02. When a draft feature becomes part of a future update to the specification any version suffix will be removed. Draft features that are deemed not appropriate for inclusion MUST be marked with the **not-recommended** label. Draft-features that are considered suitably specified and have had successful pilot implementations will be marked with the **recommended** label. If a draft feature is considered to be a required feature in ALL implementations, it will be marked with a **required** label. +New features in GitHub Issues will be **labeled** with the **feature-stage** label and will be initially labelled as **proposed, draft, recommended, required or not-recommended**. When the proposal is considered sufficiently stable for pilot implementation, it will be labeled **recommended**. If during the development of a draft feature, it is determined that the feature needs to change in a way that may break existing draft implementations, the “draft” feature-stage name itself may be versioned with a version suffix. e.g. draft-02. When a draft feature becomes part of a future update to the specification any version suffix will be removed. Draft features that are deemed not appropriate for inclusion MUST be marked with the **not-recommended** label. Draft-features that are considered suitably specified and have had successful pilot implementations will be marked with the **recommended** label. If a draft feature is considered to be a required feature in ALL implementations, it will be marked with a **required** label. Not all future new features will be introduced in this way. Some new features impact the specification in ways that cannot be encapsulated in this way. However, where a new feature can be introduced in this way, it should be. diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 164b61cb..3b01c4c7 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -22,12 +22,12 @@ This document is intended for the following audience. # Prerequisites 1. Readers must have a working knowledge of git -2. Readers should also know how open-source repositories are managed on Github. +2. Readers should also know how open-source repositories are managed on GitHub. 3. Readers must have knowledge and understanding of beckn protocol specification # Context -Beckn protocol exists as a set of specifications documented within public repositories on Github at https://github.com/beckn. These repositories contain specification documents, reference implementations, tools and utilities. Like all version controlled open-source repositories, there are processes that must be adopted to manage changes to the files present in these repositories. The most common way a change is proposed to the specification is via an Issue linked to that repository which ultimately gets converted to a Pull Request linked to that Issue. These pull requests must then be reviewed by the maintainers of the repository and subsequently merged with the main / master branch of that repository. +Beckn protocol exists as a set of specifications documented within public repositories on GitHub at https://github.com/beckn. These repositories contain specification documents, reference implementations, tools and utilities. Like all version controlled open-source repositories, there are processes that must be adopted to manage changes to the files present in these repositories. The most common way a change is proposed to the specification is via an Issue linked to that repository which ultimately gets converted to a Pull Request linked to that Issue. These pull requests must then be reviewed by the maintainers of the repository and subsequently merged with the main / master branch of that repository. # Abstract @@ -37,7 +37,7 @@ The evolution of beckn protocol specification is always use-case driven. The Cor # Terminology 1. **Git:** A decentralized version control software -2. **Github:** An online platform for managing shared repositories via git +2. **GitHub:** An online platform for managing shared repositories via git 3. **Pull Request:** A request to merge a change to an existing version of the repository 4. **Core Working Group:** Current maintainer of the specification @@ -203,7 +203,7 @@ There could be more than one person in the group qualified for an Administrator 3. Implementation expertise across multiple technologies 4. In-depth understanding of beckn protocol design principles and its applications 5. Open-source experience -6. Experience with Git and Github management +6. Experience with Git and GitHub management ### Core Committers @@ -326,7 +326,7 @@ The duration of the working group meetings can be set by the Working Group Admin **GitHub** is the medium of record for all spec designs, use cases, and so on. -All the specification documents are present on the official beckn protocol Github account [here](https://github.com/beckn). +All the specification documents are present on the official beckn protocol GitHub account [here](https://github.com/beckn). ## Sources of Truth diff --git a/MAINTAINERS.md b/MAINTAINERS.md index f528d719..d8be91c4 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -1,8 +1,8 @@ # Ravi Prakash -* __Github__ : [ravi-prakash-v](https://github.com/ravi-prakash-v) +* __GitHub__ : [ravi-prakash-v](https://github.com/ravi-prakash-v) # Pramod Varma -* __Github__ : [pramodkvarma](https://github.com/pramodkvarma) +* __GitHub__ : [pramodkvarma](https://github.com/pramodkvarma) # Venkataraman Mahadevan -* __Github__ : [venkatramanm](https://github.com/venkatramanm) +* __GitHub__ : [venkatramanm](https://github.com/venkatramanm) diff --git a/README.md b/README.md index 19a71d1b..e18a0891 100644 --- a/README.md +++ b/README.md @@ -37,9 +37,9 @@ metaDescription: "Domain agnostic transaction specification for e-commerce" This server-to-server communication protocol allows any consumer facing online platform to discover and transact with any business with minimal implementation overhead. The server-to-server nature of the protocol allows rich user experiences to be built by bundling services from multiple independent platforms. -Beckn protocol decouples the demand side digital infrastructure in the form of apps and other channels from the supply side service provisioning infrastructure. It does this by making integratedservices available not just on a single platform but potentially on any online consumer interface, (online maps, messaging, wallets, voice assistant apps and devices) that have mainstream adoption in a city. +Beckn protocol decouples the demand side digital infrastructure in the form of apps and other channels from the supply side service provisioning infrastructure. It does this by making integrated services available not just on a single platform but potentially on any online consumer interface, (online maps, messaging, wallets, voice assistant apps and devices) that have mainstream adoption in a city. -Beckn is a protocol, not a platform. It adopts a decentralized architecture that obviates the need for creating a centralised platform in order to integrate services from multiple providers simultaneously ensuring privacy and security by design by enabling secure, encrypted iteractions. +Beckn is a protocol, not a platform. It adopts a decentralized architecture that obviates the need for creating a centralised platform in order to integrate services from multiple providers simultaneously ensuring privacy and security by design by enabling secure, encrypted interactions. ## Beckn Protocol - Core Specification @@ -50,7 +50,7 @@ The core specification defines APIs for the following events in e-commerce 1. Discovery - This involves activities like platform discovery, catalog browsing, filtering and item viewing 2. Ordering - This involves activities like cart building, quote calculation, checkout & payment terms agreement, and ultimately order confirmation 3. Fulfillment - This involves all post-order-creation activities like tracking, order update, cancellation and status updates -4. Post-fulfillment - The involves all post-fulfillment activities like rating, feedback, support, returns and replacements +4. Post-fulfillment - This involves all post-fulfillment activities like rating, feedback, support, returns and replacements ## Packet Structure @@ -63,7 +63,7 @@ All communication using beckn protocol have the following packet structure ## Transport Protocol -While beckn protocol it designed to be transport agnostic, it is conventional to use HTTP as the default transport protocol. Additional layers like security and trust can be layered on top of this protocol using exisiting standards like HTTPS and SSL. It is recommended that any platform implementing beckn protocol use HTTPS to secure its communication. +While beckn protocol is designed to be transport agnostic, it is conventional to use HTTP as the default transport protocol. Additional layers like security and trust can be layered on top of this protocol using existing standards like HTTPS and SSL. It is recommended that any platform implementing beckn protocol use HTTPS to secure its communication. ## Communication @@ -100,7 +100,7 @@ To protect the privacy and confidentiality of the end user, it is recommended no # Acknowledgments -The author would like to thank the following individuals for their contributions in creating the this document. (in alphabetical order): +The author would like to thank the following individuals for their contributions in creating this document. (in alphabetical order): Pramod Varma, Beckn Foundation Sujith Nair, Beckn Foundation diff --git a/docs/BECKN-001-Layering-Network-Policy-Draft-01.md b/docs/BECKN-001-Layering-Network-Policy-Draft-01.md index b3676562..9558bc5b 100644 --- a/docs/BECKN-001-Layering-Network-Policy-Draft-01.md +++ b/docs/BECKN-001-Layering-Network-Policy-Draft-01.md @@ -19,7 +19,7 @@ Protocol Draft December 10, 2021 ## Expires on: -December 10, 2022 or Date of publication of next draft which ever is earlier +December 10, 2022 or Date of publication of next draft whichever is earlier ## License: CC-BY-ND @@ -50,7 +50,7 @@ Readers of this document must: Beckn protocol is a set of specifications that enables any two platforms to perform commercial transactions by implementing an API with standard action calls and schema. These specifications are by-design generic and therefore, sector agnostic. However, to establish a smart contract between a BAP and a BPP, additional domain-specific information must sometimes be transmitted between the platforms. For example, a logistics network might have different allowed values for the types of fulfillments it supports like “HOME-DELIVERY” and “STORE-PICKUP” as opposed to an education network where the allowed values may be “TELE-CONSULTATION” or “PHYSICAL-CONSULTATION''. These values are not standardized in the core schema but rather exist as _policies_ framed by the architects of a beckn-enabled open commerce network. -Similarly, a network might put a limit on the number of matched items that can be returned in a single catalog object. To maintain interoperability but also allow its configurability, beckn protocol specification governance restricts modification of the core schema and actions. However, to allow its adaptability, instead of forcing all specification users to adhere to the core specification and, beckn protocol governance allows creation of network-specific policies. These policies allow sector-agnostic rules and validation criteria to be published along with the specification based on recommendations and comments received from various ecosystem contributors and network participants implementing the protocol. These rules and policies must be layered on the core specification and published as a separate document that can be accessed by the network participants in a machine readable manner. +Similarly, a network might put a limit on the number of matched items that can be returned in a single catalog object. To maintain interoperability but also allow its configurability, beckn protocol specification governance restricts modification of the core schema and actions. However, to allow its adaptability, instead of forcing all specification users to adhere to the core specification and, beckn protocol governance allows creation of network-specific policies. These policies allow sector-agnostic rules and validation criteria to be published along with the specification based on recommendations and comments received from various ecosystem contributors and network participants implementing the protocol. These rules and policies must be layered on the core specification and published as a separate document that can be accessed by the network participants in a machine-readable manner. # Abstract diff --git a/docs/BECKN-002-Payments-On-Beckn-Enabled-Networks.md b/docs/BECKN-002-Payments-On-Beckn-Enabled-Networks.md index 2c6984cd..eb327590 100644 --- a/docs/BECKN-002-Payments-On-Beckn-Enabled-Networks.md +++ b/docs/BECKN-002-Payments-On-Beckn-Enabled-Networks.md @@ -20,7 +20,7 @@ Protocol Draft December 10, 2021 ## Expires on: -April 05, 2022 or Date of publication of next draft which ever is earlier +April 05, 2022 or Date of publication of next draft whichever is earlier ## License: CC-BY-ND diff --git a/docs/BECKN-003-Beckn-Protocol-Communication-Draft-01.md b/docs/BECKN-003-Beckn-Protocol-Communication-Draft-01.md index a9402e50..bafbc722 100644 --- a/docs/BECKN-003-Beckn-Protocol-Communication-Draft-01.md +++ b/docs/BECKN-003-Beckn-Protocol-Communication-Draft-01.md @@ -22,7 +22,7 @@ December 10, 2021 July 02, 2024 ## Expires on -December 10, 2024 or Date of publication of next draft which ever is earlier +December 10, 2024 or Date of publication of next draft whichever is earlier ## License CC-BY-NC-SA @@ -37,7 +37,7 @@ CC-BY-NC-SA # Abstract Communication on beckn enabled networks is server-to-server. Server-to-server means that communication between any two systems on a beckn network does not involve the client application (like the website or the mobile app). The client is thus free to render the data in whatever form chosen by the product. -Secondly, all communication is asynchronous. Asynchronous API calls do not block (or wait) for the response to return from the receiver server in the same session. This is done to replicate real-world behaviour of economic transactions across various domains and use cases. For example, a hotel booking confirmation request does not _always_ get a response in the same session. Sometimes the customer needs to wait for 24 hours or more to receive a confirmation. Sometimes the provider needs to send information to the consumer without them explicitly requesting it like in the case of a driver cancelling a confirmed ride before pickup. Such asynchronocity avoids the BAP continously polling the BPP until it receives a status update. Instead, an immediate acknowledgment is sent to the BAP in the same session and the actual response from the BPP is in the form of a callback API call to the BAP. The above two features provide a remarkable advantage as all sorts of innovations are possible in the application layer due to the experience layer being unbundled from the session and presentation layer of the application. +Secondly, all communication is asynchronous. Asynchronous API calls do not block (or wait) for the response to return from the receiver server in the same session. This is done to replicate real-world behavior of economic transactions across various domains and use cases. For example, a hotel booking confirmation request does not _always_ get a response in the same session. Sometimes the customer needs to wait for 24 hours or more to receive a confirmation. Sometimes the provider needs to send information to the consumer without them explicitly requesting it like in the case of a driver cancelling a confirmed ride before pickup. Such asynchronous nature avoids the BAP continuously polling the BPP until it receives a status update. Instead, an immediate acknowledgment is sent to the BAP in the same session and the actual response from the BPP is in the form of a callback API call to the BAP. The above two features provide a remarkable advantage as all sorts of innovations are possible in the application layer due to the experience layer being unbundled from the session and presentation layer of the application. # Introduction A beckn enabled network has multiple entities communicating with each other via standard protocol APIs. The following types of communication are possible. diff --git a/docs/BECKN-004-Policy-Administration-On-Beckn-Enabled-Networks.md b/docs/BECKN-004-Policy-Administration-On-Beckn-Enabled-Networks.md index a21f436b..bedcf7ad 100644 --- a/docs/BECKN-004-Policy-Administration-On-Beckn-Enabled-Networks.md +++ b/docs/BECKN-004-Policy-Administration-On-Beckn-Enabled-Networks.md @@ -19,7 +19,7 @@ Protocol Draft December 10, 2021 ## Expires on: -December 10, 2022 or Date of publication of next draft which ever is earlier +December 10, 2022 or Date of publication of next draft whichever is earlier ## License: CC-BY-ND @@ -118,7 +118,7 @@ This should be a prime directive of any Network Policy. Before designing a new p All policy documents must be available and agreeable via an API. ## Machine Readability -All policy administrators must strive to encode all policies in a machine readable format. This is of course not mandatory but merely a principle for the administrators to adopt as much as possible. In those cases where policies are subjective and cannot be encoded, they should be present as URLs to pdf documents +All policy administrators must strive to encode all policies in a machine-readable format. This is of course not mandatory but merely a principle for the administrators to adopt as much as possible. In those cases where policies are subjective and cannot be encoded, they should be present as URLs to pdf documents ## Non-repudiability All policies in machine-readable or document format must be accompanied with digital signatures. These signatures must be digitally verifiable by NPs using public keys. diff --git a/docs/BECKN-005-Error-Codes-Draft-01.md b/docs/BECKN-005-Error-Codes-Draft-01.md index a7208710..dd29e885 100644 --- a/docs/BECKN-005-Error-Codes-Draft-01.md +++ b/docs/BECKN-005-Error-Codes-Draft-01.md @@ -16,7 +16,7 @@ Protocol Draft January 21, 2022 ## Expires on: -January 20, 2023 or Date of publication of next draft which ever is earlier +January 20, 2023 or Date of publication of next draft whichever is earlier ## License: CC-BY-ND diff --git a/docs/BECKN-006-Signing-Beckn-APIs-In-HTTP-Draft-01.md b/docs/BECKN-006-Signing-Beckn-APIs-In-HTTP-Draft-01.md index efe78038..2a944bfe 100644 --- a/docs/BECKN-006-Signing-Beckn-APIs-In-HTTP-Draft-01.md +++ b/docs/BECKN-006-Signing-Beckn-APIs-In-HTTP-Draft-01.md @@ -34,7 +34,7 @@ The KeyID is a string that uniquely identifies a subscriber's key(s) on the netw 3. `algorithm` : The signing algorithm used. Its value is same as the value in the `algorithm` attribute as per recommendations in [Signing HTTP Messages](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12) #### algorithm: -This is the signing algorithm used for generating the signature. As per current specificaiton, it is recommended to use `ed25519` as its value. +This is the signing algorithm used for generating the signature. As per current specification, it is recommended to use `ed25519` as its value. #### created Contains the timestamp when the signature was created diff --git a/docs/BECKN-009-Tags-the-Edge-of-Beckn.md b/docs/BECKN-009-Tags-the-Edge-of-Beckn.md index a509ef2b..6a684424 100644 --- a/docs/BECKN-009-Tags-the-Edge-of-Beckn.md +++ b/docs/BECKN-009-Tags-the-Edge-of-Beckn.md @@ -46,7 +46,7 @@ PRs : TODO ## Errata -No Errata exists as of now +No Errata exist as of now # Context @@ -158,14 +158,14 @@ The Tag schema is shown below. components: schemas: Tag: - description: A simple read-only key-value store which is used to contain extended metadata for search optimization, recommendations, and general information display purposes. Tags are read-only can cannot be changed once set. + description: A simple read-only key-value store which is used to contain extended metadata for search optimization, recommendations, and general information display purposes. Tags are read-only cannot be changed once set. type: object properties: code: description: The machine-readable name of the tag. Beckn protocol will reserve certain keywords from being re-defined in any namespaces. type: string name: - description: The human-readable name of the tag. This set by the BPP and rendered as-is by the BAP + description: The human-readable name of the tag. This is set by the BPP and rendered as-is by the BAP type: string value: description: The value of the tag @@ -195,7 +195,7 @@ This section contains recommendations for entities using the Tag schema. 2. BPPs must mandatorily send the tags that have been mandated by the network policy 3. The value of the “key” field is recommended to be in the snake-case format. 4. Non-standard tags must be prefixed by a namespace defined by the creator of the tags. To ensure namespace uniqueness, it is recommended that the namespace contain the FQDN of the creator of the tag. -5. BPPs are recommended index their catalog, carts and order books using these tags to allow better searchability +5. BPPs are recommended to index their catalog, carts and order books using these tags to allow better searchability ### For BAPs diff --git a/docs/README.md b/docs/README.md index e05935f3..aeca40a9 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,5 +1,5 @@ # Protocol Drafts -These files contain specifications that have been selected from the proposals submitted to the beckn protocol specifications. The are currently under review by different working groups in the various categories supported beckn protocol governance. +These files contain specifications that have been selected from the proposals submitted to the beckn protocol specifications. They are currently under review by different working groups in the various categories supported by beckn protocol governance. After sufficient deliberation, these drafts may be published as a Protocol Standard. \ No newline at end of file