jiebi/CodeConvo huggingface dataset:
Code change:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

Related discussion:
text: (this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins> urn:ietf:params:push:sub
Code change:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

Related discussion:
text: (this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins>
Code change:
Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.

Related discussion:
text: monitor for new push messages. Requesting the delivery of events is particularly important for the <del> Web Push API.  The subscription, management and monitoring functions </del> <ins> W3C Push API.  The subscription, management and monitoring functions </ins> are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords.
Code change:
Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.

Related discussion:
text: 8.4. <del> Discarding unwanted messages at the user agent based on message authentication doesn't protect against a denial of service attack on the user agent.  Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves. </del> <ins> A user agent can control where valid push messages originate by limiting the distribution of push URIs to authorized application servers.  Ensuring that push URIs are hard to guess ensures that only application servers that have received a push URI can use it. Push messages that are not successfully authenticated by the user agent will not be delivered, but this can present a denial of service risk.  Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves. </ins> <del> An application can limit where valid push messages can originate by limiting the distribution of push URIs to authorized entities. Ensuring that push URIs are hard to guess ensures that only application servers that have been given a push URI can use it. </del> <ins> To address this case, the API has adopted I-D.ietf-webpush-vapid, which allows a user agent to restrict a subscription to a specific application server.  The push service can then identity and reject unwanted messages without contacting the user agent. </ins> A malicious application with a valid push URI could use the greater resources of a push service to mount a denial of service attack on a
Code change:
Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.

Related discussion:
text: A push service or user agent MAY also delete that receive too many push messages. <del> End-to-end confidentiality mechanisms, such as those in API, prevent an entity with a valid push message subscription URI from learning the contents of push messages.  Push messages that are not successfully authenticated will not be delivered by the API, but this can present a denial of service risk. Conversely, a push service is also able to deny service to user agents.  Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages. </del> <ins> A push service is also able to deny service to user agents. Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages. </ins> 8.5. <del> Server request logs can reveal subscription-related URIs.  Acquiring a push message subscription URI enables the receipt of messages or deletion of the subscription.  Acquiring a push URI permits the sending of push messages.  Logging could also reveal relationships between different subscription-related URIs for the same user agent. Encrypted message contents are not revealed to the push service. Limitations on log retention and strong access control mechanisms can ensure that URIs are not learned by unauthorized entities. </del> <ins> Server request logs can reveal subscription-related URIs or relationships between subscription-related URIs for the same user agent.  Limitations on log retention and strong access control mechanisms can ensure that URIs are not revealed to unauthorized entities. </ins> 9.
Code change:
Found some minor stuff in the draft, and had two questions (below). If I should send those to the list instead, let me know :) Does an application server have to have a unique keypair? E.g lets say I have multiple application servers sitting behind a load balancer, could I just share the keys used for vapid between them? In 5.2: Why is a MAY? If I, as a UA, create a restricted subscription my assumption would be that that is actually checked, right? If the Push Service is not planning to check it anyway, wouldn't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time?
The concept of an application server does not define the quantity— it's fine for multiple servers to share a single key. Martin added text allowing additional claims () which further clarifies that it's fine to include more specific information, for example which server created the message, which is useful if the push service has means for dealing with this. (E.g. QoS or analytics.) I don't recall why that's a MAY. We certainly shouldn't forward unauthorized messages for restricted subscriptions to the user. /cc NAME The changes themselves look good, thanks! :)
Thanks for the explanation NAME Should I open an issue regarding the ?

Related discussion:
text: 2. <del> Application servers that wish to self-identity generate and maintain </del> <ins> Application servers that wish to self-identify generate and maintain </ins> a signing key pair.  This key pair MUST be usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes an identity for the
Code change:
Found some minor stuff in the draft, and had two questions (below). If I should send those to the list instead, let me know :) Does an application server have to have a unique keypair? E.g lets say I have multiple application servers sitting behind a load balancer, could I just share the keys used for vapid between them? In 5.2: Why is a MAY? If I, as a UA, create a restricted subscription my assumption would be that that is actually checked, right? If the Push Service is not planning to check it anyway, wouldn't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time?
The concept of an application server does not define the quantity— it's fine for multiple servers to share a single key. Martin added text allowing additional claims () which further clarifies that it's fine to include more specific information, for example which server created the message, which is useful if the push service has means for dealing with this. (E.g. QoS or analytics.) I don't recall why that's a MAY. We certainly shouldn't forward unauthorized messages for restricted subscriptions to the user. /cc NAME The changes themselves look good, thanks! :)
Thanks for the explanation NAME Should I open an issue regarding the ?

Related discussion:
text: 2.1. If the application server wishes to provide contact details it MAY <del> include an "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </del> <ins> include a "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </ins> include a contact URI for the application server as either a "mailto:" (email) RFC6068 or an "https:" RFC2818 URI.
Code change:
Found some minor stuff in the draft, and had two questions (below). If I should send those to the list instead, let me know :) Does an application server have to have a unique keypair? E.g lets say I have multiple application servers sitting behind a load balancer, could I just share the keys used for vapid between them? In 5.2: Why is a MAY? If I, as a UA, create a restricted subscription my assumption would be that that is actually checked, right? If the Push Service is not planning to check it anyway, wouldn't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time?
The concept of an application server does not define the quantity— it's fine for multiple servers to share a single key. Martin added text allowing additional claims () which further clarifies that it's fine to include more specific information, for example which server created the message, which is useful if the push service has means for dealing with this. (E.g. QoS or analytics.) I don't recall why that's a MAY. We certainly shouldn't forward unauthorized messages for restricted subscriptions to the user. /cc NAME The changes themselves look good, thanks! :)
Thanks for the explanation NAME Should I open an issue regarding the ?

Related discussion:
text: An application server requests the delivery of a push message as described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field <del> with credentials that use the "WebPush" authentication scheme auth and a Crypto-Key header field that includes its public key key. </del> <ins> with credentials that use the "WebPush" authentication scheme (auth) and a Crypto-Key header field that includes its public key (key). </ins> Note that the header fields shown in ex-push don't include line wrapping.  Extra whitespace is added to meet formatting constraints.
Code change:
Consider a client that does Since the ICE gathering process has started at the time of , it is too late at this point to call . Thus, a way is needed to find the set of ICE servers before the offer is POSTed to the server. In his mail of 12 July 2022, Sergio suggests a different procedure: This alternate procedure should work, but it is somewhat unusual; thus, the spec should describe this procedure in detail, and indicate that this is the procedure that the WHIP client must use if it wishes to use the server-provided ICE servers. What is more, with this procedure the posted offer does not contain any local candidates, which might imply that client-side Trickle ICE is a requirement, at least in some environments. Again, this should be discussed in the draft.
That is not true. If server is on a public IP address or behind a port forwarding NAT. The candidates sent by the server are enough to establish the ICE connection. Gathering all the ICE candidates on the local offer are only required if the client does not support trickle and the server is behind of a NAT that requires hole punching. I don't think we should explain how to use webrtc apis in the spec.
So WHIP is restricted to the case where the server is on a public IP, with no firewall? That would be fine with me, but if that's the case then IMHO it needs to be stated explicitly in the draft. What happens if the client is on a restrictive network that only lets outgoing TCP through, which is unfortunately still the case in many university networks? Are you assuming that the server supports passive TCP ICE? If so, should that be mentioned in the draft somewhere?
The turn server configuration via OPTIONS is not going to be removed. I can add a note like:

Related discussion:
text: server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent. <ins> NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase. </ins> The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTION request processing and increase the processing required to