cosmetic fixes

text/0000-ember-data-identifiers.md

@@ -98,7 +98,7 @@ from their API for the session to correctly match the payloads to the record.
 ### Better Cache Serialization & Improved Infra for Offline Support
 
 In order to enable users to achieve full offline support, or to serialize the store 
- or transport across the wire (for example as an advanced  fastboot rehydration mode)
+ or transport across the wire (for example as an advanced fastboot rehydration mode)
 the entire state of the store needs to be serializable. This RFC introduces the 
 foundation for mechanisms through which this can be later achieved.
 
@@ -112,7 +112,7 @@ export interface Identifier {
 }
 
 export interface RecordIdentifier extends Identifier {
-  id: string | null;
+  id?: string | null;
   type: string;
 }
 ```
@@ -132,7 +132,7 @@ In an ideal world, the `lid` of each `Identifier` would be a `v4` [uuid](https:/
 Each underlying primitive will have its own bucket, as new primitives are formalized, new
  buckets will emerge. Initially we expect only a `record` bucket which aligns with today's
 `IdentityMap` cache for `Record`s. Examples of future buckets may include a cache for 
-`queries`, `documents`, `transactions` `operations` `errors`, `meta` or any number of other
+`queries`, `documents`, `transactions`, `operations`, `errors`, `meta` or any number of other
  concepts that represent state required to be serializable.
 
 In our ideal world, the `lid` would then be a `uuid-v4` that is practically unique across
@@ -606,7 +606,7 @@ export interface StableIdentifier {
   [DEBUG_IDENTIFIER_BUCKET]: string;
 }
 
-export interface RecordIdentifier extends StableIdentifier {
+export interface StableRecordIdentifier extends StableIdentifier {
   id: string | null;
   type: string;
   [DEBUG_CLIENT_ORIGINATED]: boolean;