Draft: draft-ietf-ppm-dap

Commentary: This change is basically a search - and - replace for /ppm / dap/. However , I have also re - aligned the context strings to match the next draft that will be cut ( -01 ) . I think the change is mostly correct , my main concern is the " URN Sub - namespace for PPM ( urn : ietf : params : dap ) " section . : Does it make sense for all drafts in the PPM WG to share the namespace , or do we want to define one specifically for DAP ? 
 Before merging I would appreciate an answer on the question I raised above . I want to make sure the URN bits are correct . 
 Separate namespaces seems better , especially if we 're thinking of DAP and STAR . Names are cheap , after all . 
 Separate namespaces , because otherwise I think we 'd have to write a further document enumerating the error type URNs that both this document and other PPM drafts like STAR could reference . We should avoid spreading the specification across multiple documents more than necessary . Maybe including the WG in the URN path like helps ? 
 Here 's the RFC defining It 's pretty loosely structured , and the existing sub - namespaces from published RFCs appear to just be named after protocols and formats , not working groups . 
 I took suggestion of prefixing the dap space with ppm .
Paragraph (version A):
In the remainder of this document, we use the tokens in the table
above to refer to error types, rather than the full URNs.  For
example, an "error of type 'unrecognizedMessage'" refers to an error
document with "type" value
"urn:ietf:params:ppm:error:unrecognizedMessage".
Paragraph (version B):
In the remainder of this document, we use the tokens in the table
above to refer to error types, rather than the full URNs.  For
example, an "error of type 'unrecognizedMessage'" refers to an error
document with "type" value
"urn:ietf:params:ppm:dap:error:unrecognizedMessage".
Paragraph (version A):
Let "[aggregator]" denote the helper's API endpoint.  The leader
sends a POST request to "[aggregator]/aggregate" with its
AggregateInitializeReq message as the payload.  The media type is
"message/ppm-aggregate-initialize-req".  In addition, this request
MUST be authenticated as described in https-sender-auth.
Paragraph (version B):
Let "[aggregator]" denote the helper's API endpoint.  The leader
sends a POST request to "[aggregator]/aggregate" with its
AggregateInitializeReq message as the payload.  The media type is
"message/dap-aggregate-initialize-req".  In addition, this request
MUST be authenticated as described in https-sender-auth.
Paragraph (version A):
The helper's response to the leader is an HTTP 200 OK whose body is
the AggregateInitializeResp and media type is "message/ppm-aggregate-
initialize-resp".
Paragraph (version B):
The helper's response to the leader is an HTTP 200 OK whose body is
the AggregateInitializeResp and media type is "message/dap-aggregate-
initialize-resp".
Paragraph (version A):
For each aggregator endpoint "[aggregator]" in
"AggregateContinueReq.task_id"'s parameters except its own, the
leader sends a POST request to "[aggregator]/aggregate" with
AggregateContinueReq as the payload and the media type set to
"message/ppm-aggregate-continue-req".  In addition, this request MUST
be authenticated as described in https-sender-auth.
Paragraph (version B):
For each aggregator endpoint "[aggregator]" in
"AggregateContinueReq.task_id"'s parameters except its own, the
leader sends a POST request to "[aggregator]/aggregate" with
AggregateContinueReq as the payload and the media type set to
"message/dap-aggregate-continue-req".  In addition, this request MUST
be authenticated as described in https-sender-auth.
Paragraph (version A):
The order of AggregateContinueResp.prepare_shares MUST match that of
the PrepareStep values in "AggregateContinueReq.prepare_shares".  The
helper's response to the leader is an HTTP 200 OK whose body is the
AggregateContinueResp and media type is "message/ppm-aggregate-
continue-resp".  The helper then awaits the next message from the
leader.
Paragraph (version B):
The order of AggregateContinueResp.prepare_shares MUST match that of
the PrepareStep values in "AggregateContinueReq.prepare_shares".  The
helper's response to the leader is an HTTP 200 OK whose body is the
AggregateContinueResp and media type is "message/dap-aggregate-
continue-resp".  The helper then awaits the next message from the
leader.