jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-webpush-encryption

Commentary: Two relatively small changes .
For efficiency reasons, multiple users of Web Push often share a
central agent that aggregates push functionality.  This agent can
enforce the use of this encryption scheme by applications that use
push messaging.  An agent that only delivers messages that are
properly encrypted strongly encourages the end-to-end protection of
messages.
Multiple users of Web Push often share a central agent that
aggregates push functionality.  This agent can enforce the use of
this encryption scheme by applications that use push messaging.  An
agent that only delivers messages that are properly encrypted
strongly encourages the end-to-end protection of messages.
Draft: draft-ietf-webpush-encryption

Commentary: This is the best that I can do for this one .. 
 I think this is as good as it gets .
A push message MUST include the application server ECDH public key in
the "keyid" parameter of the encrypted content coding header.  The
uncompressed point form defined in X9.62 (that is, a 65 octet
sequence that starts with a 0x04 octet) forms the entirety of the
"keyid".
A push message MUST include the application server ECDH public key in
the "keyid" parameter of the encrypted content coding header.  The
uncompressed point form defined in X9.62 (that is, a 65 octet
sequence that starts with a 0x04 octet) forms the entirety of the
"keyid".  Note that this means that the "keyid" parameter will not be
valid UTF-8 as recommended in RFC8188.
Draft: draft-ietf-webpush-encryption

Commentary: /cc Not sure about " parameter of that same header " phrasing . Not a fan of duplicating the text about the content coding header either . Suggestions ? 
 Yep , these are both correct . Thanks .
When sending a message, an Application Server generates an ECDH key
pair and a random salt.  The ECDH public key is encoded into the "dh"
parameter of the Crypto-Key header field; the salt is encoded into
message payload.  The ECDH key pair can be discarded after encrypting
the message.
When sending a message, an Application Server generates an ECDH key
pair and a random salt.  The ECDH public key is encoded into the
"keyid" parameter of the encrypted content coding header, the salt in
the "salt" parameter of that same header (see Section 2.1 of I-
D.ietf-httpbis-encryption-encoding).  The ECDH key pair can be
discarded after encrypting the message.
An Application combines its ECDH private key with the public key
provided by the User Agent using the process described in ECDH; on
receipt of the push message, a User Agent combines its private key
with the public key provided by the Application Server in the "dh"
parameter in the same way.  These operations produce the same value
for the ECDH shared secret.
An Application combines its ECDH private key with the public key
provided by the User Agent using the process described in ECDH; on
receipt of the push message, a User Agent combines its private key
with the public key provided by the Application Server in the "keyid"
parameter in the same way.  These operations produce the same value
for the ECDH shared secret.
Draft: draft-ietf-webpush-encryption

Commentary: defines : This removes a number of edge - cases and simplifies implementations . However , defines : Which is a violation of the former . Semantically it makes most sense for these to be distinct values since they 're intended for different audiences . I 'll propose a PR limiting webpush - encryption to one Crypto - Key entry having a value instead . 
 Because life is complicated , there are some libraries that are using " ; " and creating a single parameter set containing both ECE and VAPID parameters , e.g. Because of " quirks " in both the mozilla and FCM handlers , this works . It may be beneficial if legacy push servers continue to support this behavior while libraries and applications that depend on them transition to any new division format .
An application server MUST include exactly one entry in each of the
Encryption and Crypto-Key header fields.  This allows the "keyid"
parameter to be omitted from both header fields.
An application server MUST include exactly one entry in the
Encryption field, and at most one entry having a "dh" parameter in
the Crypto-Key field.  This allows the "keyid" parameter to be
omitted from both header fields.
Draft: draft-ietf-webpush-encryption

Commentary: This tracks the changes in martinthomson / http - encryption .
User Agents that enforce encryption MUST expose an elliptic curve
Diffie-Hellman share on the P-256 curve FIPS186.  Public keys, such
as are encoded into the "dh" parameter, MUST be in the form of an
uncompressed point as described in X.692.
User Agents MUST expose an elliptic curve Diffie-Hellman share on the
P-256 curve FIPS186.
Public keys, such as are encoded into the "dh" parameter, MUST be in
the form of an uncompressed point as described in X.692 (that is, a
65 octet sequence that starts with a 0x04 octet).
The label for this curve is the string "P-256" encoded in ASCII (that
is, the octet sequence 0x50, 0x2d, 0x32, 0x35, 0x36).
Draft: draft-ietf-webpush-encryption

Commentary: was unhappy about the freedom we offered . This does n't remove the header field separation , but it removes most of it . 
 Thank you ,  ! This looks good to me .
An application server MUST NOT use other content encodings for push
messages.  In particular, content encodings that compress could
result in leaking of push message contents.  The Content-Encoding
header field therefore has exactly one value, which is "aesgcm128".
An application server MUST include exactly one entry in each of the
Encryption and Encryption-Key header fields.  This allows the "keyid"
parameter to be omitted from both header fields.
An application server MUST NOT include a "key" parameter in the
Encryption header field.