URI normalization (rfcs#8)

Migrate PRs from:
interledger/rfcs#147
interledger/rfcs#157

* Update draft number
* Make commas reserved characters in URI

Author: adrianhopebailie

src/spec/crypto-conditions.md

@@ -2,7 +2,7 @@
 coding: utf-8
 
 title: Crypto-Conditions
-docname: draft-thomas-crypto-conditions-02
+docname: draft-thomas-crypto-conditions-03
 category: std
 
 pi: [toc, sortrefs, symrefs, comments]
@@ -50,6 +50,7 @@ author:
     uri: https://www.ripple.com
 
 normative:
+    RFC3986:
     RFC3280:
     RFC4055:
     RFC4648:
@@ -173,7 +174,7 @@ Each condition type uses one or more cryptographic primitives such as digest or
 To verify that a given implementation can verify a fulfillment for a given condition, implementations MUST ensure they are able to validate fulfillments of all types indicated in the subtypes field of a compound condition. If an implementation encounters an unknown type it MUST reject the condition as it will almost certainly be unable to validate the fulfillment.
 
 ## Multi-Signature
-Crypto-conditions can abstract away many of the details of multi-sign. When a party provides a condition, other parties can treat it opaquely and do not need to know about its internal structure. That allows parties to define arbitrary multi-signature setups without breaking compatibility. That said, it is important that implementations must inspect the ypes and subtypes of any crypto-conditions they encounter to ensure they do not pass on a condition they will not be able to verify at a later stage.
+Crypto-conditions can abstract away many of the details of multi-sign. When a party provides a condition, other parties can treat it opaquely and do not need to know about its internal structure. That allows parties to define arbitrary multi-signature setups without breaking compatibility. That said, it is important that implementations must inspect the types and subtypes of any crypto-conditions they encounter to ensure they do not pass on a condition they will not be able to verify at a later stage.
 
 In many instances protocol designers can use crypto-conditions as a drop-in replacement for public key signature algorithms and add multi-signature support to their protocols without adding any additional complexity.
 
@@ -866,7 +867,13 @@ The cost parameter is the cost of the condition that is represented by the URI.
 
 ### Parameter: Subtypes (subtypes)
 
-The subtypes parameter indicates the types of conditions that are subtypes of the condition represented by the URI. The value MUST be a comma seperated list of names from the [Crypto-Condition Type Registry](#crypto-conditions-type-registry) and SHOULD not include the type of the root crypto-condition. i.e. The value of the fpt parameter should not appear in the list of types provided as the value of the subtypes parameter.
+The subtypes parameter indicates the types of conditions that are subtypes of the condition represented by the URI. The value MUST be a comma seperated list of names from the [Crypto-Condition Type Registry](#crypto-conditions-type-registry).
+
+The list MUST exclude the type of the root crypto-condition. i.e. The value of the fpt parameter should not appear in the list of types provided as the value of the subtypes parameter.
+
+The list MUST be ordered by the type id value of each type, in ascending order. i.e. preimage-sha-256 MUST appear before prefix-sha-256.
+
+The commas in the list should be treated as reserved characters per [RFC3986](#RFC3986)and not be percent encoded when used as list delimiters in the subtypes parameter.
 
 # Example Condition