Moves deterministic encoded CBOR language back to CBOR section

[jonnycrunch]

This PR undoes the editorial changes to get us back on having the discussion regarding Deterministically Encoded CBOR back to the conversations.

The language builds on the updated CBOR spec RFC #8949

---

Preview | Diff

[TallTed]

typos and line lengths

Suggested change

	To produce a deterministic canonical CBOR representation of a DID document and faciliate maximal lossless compatiblity with other
	core representations via the Abstract Data Model the following constraints of a CBOR representation of a DID Document model MUST be followed:
	To produce a deterministic canonical CBOR representation of a DID
	document and facilitate maximal lossless compatibility with other core
	representations via the Abstract Data Model the following constraints
	of a CBOR representation of a DID Document model MUST be followed:
	</p>

[TallTed]

Suggested change

	<li>Property names MUST be represented as text string (major type 3) and contain only UTF-8 strings. </li>
	<li>Undefined Values of Required Properties as defined in <a href="#data-model">the Data Model</a> that are absent from the CBOR representation SHOULD be labeled with Primitive type (major type 7) with value 23 (Undefined value). </li>
	<li>Property names in each CBOR map MUST be unique. </li>
	<li>Integer encoding MUST be as short as possible.</li>
	<li>The expression of lengths in CBOR major types 2 through 5 MUST be as short as possible. </li>
	<li>The keys in every map must be sorted lowest value to highest. Sorting is performed on the bytes of the representation of the keys. If two keys have different lengths, the shorter one sorts earlier. If two keys have the same length, the one with the lower value in (byte-wise) lexical order sorts earlier. </li>
	<li>
	Property names MUST be represented as text string (major type 3) and
	contain only UTF-8 strings.
	</li>
	<li>
	Undefined Values of Required Properties as defined in <a
	href="#data-model">the Data Model</a> that are absent from the CBOR
	representation SHOULD be labeled with Primitive type (major type 7)
	with value 23 (Undefined value).
	</li>
	<li>
	Property names in each CBOR map MUST be unique.
	</li>
	<li>
	Integer encoding MUST be as short as possible.
	</li>
	<li>
	The expression of lengths in CBOR major types 2 through 5 MUST be as
	short as possible.
	</li>
	<li>
	The keys in every map must be sorted lowest value to highest. Sorting
	is performed on the bytes of the representation of the keys. If two
	keys have different lengths, the shorter one sorts earlier. If two
	keys have the same length, the one with the lower value in (byte-wise)
	lexical order sorts earlier.
	</li>

line lengths

[iherman]

@jonnycrunch did you use a different github persona than the one you registered with the WG? Otherwise I don't know why this PR wasn't accepted.

I will set this as editorial, which will release the lock, but you should check, please. Thx

[w3cbot]

iherman marked as non substantive for IPR from ash-nazg.

[msporny]

@jonnycrunch, I'm confused by this PR. The text was already moved back in this commit: 5b7c489 which was announced to the WG here: https://lists.w3.org/Archives/Member/member-did-wg/2021Jan/0002.html

Is there some difference between the text in the spec and what you're proposing in the PR?

[brentzundel]

@jonnycrunch I believe the changes you are recommending here have already been made.

[OR13]

make no mention on canonical, based on the comments from the call... prefer to not see that language / think this should be closed.

[msporny]

@brentzundel wrote:

@jonnycrunch I believe the changes you are recommending here have already been made.

I checked a few days ago and checked again today per @jricher's request -- the changes in this PR were merged into the specification before this PR was raised. I did a line-by-line comparison.

There are wording differences due to a refactoring of language that @peacekeeper applied to the spec wrt. ADM entry keys, etc. This PR undoes some of those changes. The group also discussed this PR during the special topic call today and decided to close it.

For those reasons, this PR is marked pending close and will be closed in 7 days or when @jonnycrunch confirms that we can close this PR, whichever event happens sooner.

[msporny]

This PR is marked pending close and will be closed in 7 days or when @jonnycrunch confirms that we can close this PR, whichever event happens sooner.

7 days have elapsed since the 'pending close' tag was added with no response from @jonnycrunch, closing.