Explain 64-bit I-JSON issues but don't embed that in CDDL

Alternative to #359.

I-JSON can mess with big numbers and we can't constrain the range.
We don't want to mandate bigint support on anyone. We don't want
to make non-JSON serializers/parsers have to worry about stringified
numbers - so modifying the CDDL directly seems off.

There's lots of ways that implementations can internally handle values,
we don't care much about that here. For interop, settle on allow JSON parsers
to write uint64 as strings if they want to. Make it clear that parsers
should expect that, unless they have some non-standard way of knowing.

Fixes #229

draft-ietf-quic-qlog-main-schema.md

@@ -1304,7 +1304,7 @@ as each record by itself is a valid JSON object).
 
 ## JSON Interoperability {#json-interop}
 
-Some JSON parsers have issues with the full JSON format, especially those
+Some JSON implementations have issues with the full JSON format, especially those
 integrated within a JavaScript environment (e.g., Web browsers, NodeJS). I-JSON
 (Internet-JSON) is a subset of JSON for such environments; see
 {{!I-JSON=RFC7493}}. One of the key limitations of JavaScript, and thus I-JSON,
@@ -1316,18 +1316,13 @@ To accommodate such constraints in CDDL, {{Appendix E of CDDL}} recommends
 defining new CDDL types for int64 and uint64 that limit their values to the
 restricted 64-bit integer range. However, some of the protocols that qlog is
 intended to support (e.g., QUIC, HTTP/3), can use the full range of uint64
-values. To support this, qlog defines a uint64 type that allows a string- or
-numeric-based representation.
+values.
 
-As such, when using I-JSON in these situations, the following CDDL definition of
-uint64 should override the original and parsers should take into account that a
-uint64 field can either be a number or string.
-
-~~~
-uint64 = text /
-         uint .size 8
-~~~
-{: #cddl-ijson-uint64-def title="Custom uint64 definition for I-JSON"}
+As such, to support situations where I-JSON is in use, seralizers MAY encode
+uint64 values using JSON strings. JSON parsers, therefore, SHOULD support
+parsing of strings or numbers into uint64 unless there is out-of-band
+information indicating that neither the serializer or parser are constrained by
+I-JSON.
 
 ## Truncated values {#truncated-values}