Ordering of subtypes and query string parameters in URI form

[adrianhopebailie]

The URI form of conditions should probably define some rules for determining equality. A direct string comparison is not appropriate because there are no rules that define the order of URI query strings nor the order of the subtypes.

The RFC should be explicit that URI normalization and comparison follow the rules as defined in RFC 3986 and the tests should folllow these rules for testing too

[justmoon]

I'd prefer having a standard canonicalization, so that you can just string compare. That way you can also use it as an index.

Although I'm starting to think it would be better to just index it using the DER which is already canonical.

[adrianhopebailie]

Although I'm starting to think it would be better to just index it using the DER which is already canonical.

+1 - URI comparisons is already well defined, I'd prefer to leverage it rather than force people to treat the URI as a string.

We may find that has advantages in future

[adrianhopebailie]

There is no standard for arrays as query string parameter values. We have gone with a comma separated list for the subtypes parameter which means we should either define a strict ordering or say that ordering must be ignored when comparing.

[adrianhopebailie]

I propose a strict ordering to allow for string based matching on query string parameters which would work for any generic URI matching algorithms

[sappenin]

I have created a PR (#25) that further clarifies the canonical ordering that we all seem to have agreed upon in this issue, including the ordering of subtype values as well as the ordering of all query-params in the URI.

[sappenin]

Bump...

[adrianhopebailie]

Resolved in #25