Add non normative section about managing status list

[PatStLouis]

This is an attempt to address #232

Some text is proposed here which should be reviewed.

---

Preview | Diff

[PatStLouis]

This PR was discussed on a call and it was suggested to add this as an appendix with SHOULD normative requirement applicable for implementers of bitstring status list.

[msporny]

Hmm, probably shouldn't do normative requirements in an appendix.

[PatStLouis]

all normative text has been removed in favor of "nudge" type wording, such as "are encouraged to"

[dlongley]

A note about our implementation, we receive these properties:

  properties: {
    credentialId: {
      type: 'string'
    },
    // an ID value required to unambiguously identify index allocation state
    indexAllocator: {
      // an ID (URL) referring to an index allocator
      type: 'string',
      pattern: '^(.+):(.+)$'
    },
    type: {
      type: 'string',
      // supported types in this version
      enum: [
        'BitstringStatusList'
      ]
    },
    // length of the status list in bits
    length: {
      type: 'number',
      min: 8,
      max: MAX_LIST_SIZE
    },
    statusPurpose: {
      type: 'string'
    }
  }

[PatStLouis]

Discussed:
For creation, consider returning a 204 with location header, instead of the credential being returned in the body. Maybe consider having an options field for returning the credential as well.

Review usage of 204 across the specification. Determine if 201 or 204 is suitable for this operation.

Always send location header, make response body optional (TBD).

[PatStLouis]

Lets review next week, potentially open a separate issue for creation endpoint details (status code / response body)

[PatStLouis]

issue #594 was created to discuss indexAllocator further.