Merge pull request #5 from onflow/fxamacker/update-readme-for-1.0.0-RC3

Update README for 1.0.0-RC3:
- Status: added to describe status of CCF specs and codec
- Abstract: removed
- Introduction: copied from ccf_specs.md RC3

Author: fxamacker

README.md

@@ -3,23 +3,15 @@
 
 CCF is defined in [ccf_specs.md](ccf_specs.md).
 
-The [CCF codec](https://github.com/onflow/cadence/tree/master/encoding/ccf) in Cadence is used for encoding events in CCF.  However, some CCF options are not yet implemented in the codec.
+## Status
 
-"Abstract" and "Introduction" sections in this README were copied from the CCF specs.  Additional content such as benchmarks will be added to the README later.
+CCF 1.0.0-RC3 is partially supported by the [CCF codec](https://github.com/onflow/cadence/tree/master/encoding/ccf) deployed in [June 2023 spork](https://developers.flow.com/concepts/nodes/node-operation/upcoming-sporks).
 
-## Abstract
+The CCF codec in Cadence is currently used for encoding events in CCF.  Some CCF options (partially self-describing mode) are not yet implemented by the codec.
 
-Cadence Compact Format (CCF) is a data format designed for compact, efficient, and deterministic encoding of [Cadence](https://github.com/onflow/cadence) external values.
+New Cadence types added to Cadence after August 4, 2023 are not yet added to CCF specs.
 
-Cadence is a resource-oriented programming language that introduces new features to smart contract programming.  It's used by [Flow](https://github.com/onflow/flow-go) blockchain and has a syntax inspired by Swift, Kotlin, and Rust. Its use of resource types maps well to the Move language.
-
-CCF messages can be fully self-describing or partially self-describing.  Both are more compact than JSON-based messages.  CCF-based protocols can send Cadence metadata just once for all messages of that type.  Malformed data can be detected without Cadence metadata and without creating Cadence objects.
-
-CCF defines "Deterministic CCF Encoding Requirements" and makes it optional.  It allows CCF codecs implemented in different programming languages to produce the same deterministic encodings.  CCF-based formats and protocols can balance tradeoffs by specifying how they use CCF options.
-
-CCF obsoletes [JSON-Cadence Data Interchange Format](https://developers.flow.com/cadence/json-cadence-spec) (JSON-CDC) for use cases that do not require JSON.
-
-### Introduction
+## Introduction
 
 CCF is a data format that allows compact, efficient, and deterministic encoding of Cadence external values.
 
@@ -32,15 +24,15 @@ The same `FeesDeducted` event on the Flow blockchain can encode to:
 
 CCF defines all requirements for deterministic encoding (sort orders, smallest encoded forms, and Cadence-specific requirements) to allow CCF codecs implemented in different programming languages to produce the same deterministic encodings.
 
-Some requirements (such as "Deterministic CCF Encoding Requirements") are defined as optional.  Each CCF-based format or protocol can have its specification state how CCF options are used.  This allows each protocol to balance tradeoffs such as compatibility, determinism, speed, encoded data size, etc.
+Some requirements (such as "Deterministic CCF Encoding Requirements") are defined as optional. Each CCF-based format or protocol can have its specification state how CCF options are used. This allows each protocol to balance trade-offs such as compatibility, determinism, speed, encoded data size, etc.
 
 CCF uses CBOR and is designed to allow efficient detection and rejection of malformed messages without creating Cadence objects. This allows more costly checks for validity, etc. to be performed only on well-formed messages.
 
-CBOR is an [Internet Standard](https://www.ietf.org/rfc/std-index.txt) defined by [IETF STD 94](https://www.rfc-editor.org/info/std94).  CBOR is designed to be relevant for decades and is used by data formats and protocols such as [W3C WebAuthn](https://www.w3.org/TR/webauthn-2/), C-DNS ([IETF RFC 8618](https://www.rfc-editor.org/rfc/rfc8618.html)), COSE ([IETF STD 96](https://www.rfc-editor.org/info/std96)), CWT ([IETF RFC 8392](https://www.rfc-editor.org/info/rfc8392)), etc.
+CBOR is an [Internet Standard](https://www.ietf.org/rfc/std-index.txt) defined by [IETF STD 94](https://www.rfc-editor.org/info/std94). CBOR is designed to be relevant for decades and is used by data formats and protocols such as [W3C WebAuthn](https://www.w3.org/TR/webauthn-2/), C-DNS ([IETF RFC 8618](https://www.rfc-editor.org/rfc/rfc8618.html)), COSE ([IETF STD 96](https://www.rfc-editor.org/info/std96)), CWT ([IETF RFC 8392](https://www.rfc-editor.org/info/rfc8392)), etc.
 
 ## History
 
-Commit history and contributions to `ccf_specs.md` file prior to Nov 29, 2022 are associated with `README.md` file.
+Commit history of `ccf_specs.md` file prior to Nov 29, 2022 are associated with `README.md` file.
 
 Old branches can be found at https://github.com/fxamacker/ccf_draft.