Draft: draft-gpew-priv-ppm

Commentary: All protocol request messages contain a field , which allows aggregators to service multiple tasks from a single set of endpoints . The exception is : since it is an HTTP GET request , there is no body , and thus no place for the client to indicate the desired to the aggregator . We do n't want to introduce a request body to , because then it would have to be a POST instead of a GET , and that would make it harder for implementations to cache HPKE config values . So instead we have clients encode the task ID in RFC 4648 Base16 ( a.k.a . hexadecimal ) and provide it as a query parameter . See issue 
 My goal here is to enable our aggregator implementations in the interop target to use one HPKE config per task . The alternative to this would be for us to use aggregator endpoints that somehow incorporate the task ID , as I described , which is already permitted by the spec as written . 
 The Base64 alphabet includes , and , which means you have to URL encode ( a.k.a . percent encode ) Base64 strings before you can use them in a URL , which is a chore and yields less readable URLs ( not that 64 character hex strings is especially user - friendly ) . An alternative would be to use RFC 4648 's , omitting the padding characters as suggested in since task IDs are of a known length . 
  . I think the main thing is to be consistent . I would either : this PR to use base64url ; or on a commit that makes all encodings of the taskID ( except those that appear in the body , of course ) the same ( i.e. , hexadecimal ) . I think ( 2 . ) would be my preference . 
 I agree with the consistency argument . I 'm leaning towards using everywhere because it 's more compact than  / hex , and also I think implementations are less likely to be surprised by case requirements in base64url ( i.e. , it 's obvious that  is case sensitive , but you have to read RFC 4648 attentively to notice that it mandates uppercase hex strings ) . 
 Base64Url sounds good to me . I took a quick look and it appears that most standard base64 libraries also support the URL encoding . 
 I will clean this up and merge it once I have implemented it in Janus and convinced myself it 's sound . 
 SGTM , but why not base64 encode the taskID for consistency with
Paragraph (version A):
This list is not exhaustive.  The server MAY return errors set to a
URI other than those defined above.  Servers MUST NOT use the PPM URN
namespace for errors not listed in the appropriate IANA registry (see
ppm-urn-space).  Clients SHOULD display the "detail" field of all
errors.  The "instance" value MUST be the endpoint to which the
request was targeted.  The problem document MUST also include a
"taskid" member which contains the associated PPM task ID, encoded
with base64 using the standard alphabet RFC4648 (this value is always
known, see task-configuration).
Paragraph (version B):
This list is not exhaustive.  The server MAY return errors set to a
URI other than those defined above.  Servers MUST NOT use the PPM URN
namespace for errors not listed in the appropriate IANA registry (see
ppm-urn-space).  Clients SHOULD display the "detail" field of all
errors.  The "instance" value MUST be the endpoint to which the
request was targeted.  The problem document MUST also include a
"taskid" member which contains the associated PPM task ID, encoded in
Base 64 using the URL and filename safe alphabet with no padding as
defined in sections 5 and 3.2 of RFC4648 (this value is always known,
see task-configuration).
Paragraph (version A):
"aggregator_endpoints": A list of URLs relative to which an
aggregator's API endpoints can be found.  Each endpoint's list
MUST be in the same order.  The leader's endpoint MUST be the
first in the list.  The order of the "encrypted_input_shares" in a
"Report" (see uploading-reports) MUST be the same as the order in
which aggregators appear in this list.
Paragraph (version B):
"aggregator_endpoints": A list of URLs relative to which an
aggregator's API endpoints can be found.  Each endpoint's list
MUST be in the same order.  The leader's endpoint MUST be the
first in the list.  The order of the "encrypted_input_shares" in a
"Report" (see uploading-reports) MUST be the same as the order in
which aggregators appear in this list.  Aggregators MAY use the
same endpoint for multiple tasks.