jiebi/CodeConvo huggingface dataset:
Code change:
Explain the different use-cases on specifying interfaces to
There's something obvious I'm not seeing: if I want to specify a multicast or link-local address for an endpoint, why not simply specify that address? What's the use of adding the interface into it? Some addresses will inherently limit interfaces; I thought interface preference was about preferring wifi to 4G, etc.
Like, in section 6.1.1:
Multicast groups can be scoped (see RFC7346), thus, may only be available on certain interfaces or even have different meanings based on the interface. So for Interface- and Link-Local scope, specifying the interface is strictly required. For others use cases (like coping with non-unique use of RFC1918 addresses) this may also be helpful.
Why does the API have both the ability to say LocalSpecifier.WithInterface and to set interface requirements on TransportProperties? Why not just keep the latter and remove the former?
There's history here: LocalSpecifier.WithInterface predates explicitly setting the interface name in interface requirements. There might be reasons to keep this: LocalSpecifier is more likely to show up in application UI than in transport properties. Any text proposed to keep both would need to have an unambiguous way to resolve conflicts between the two. This might be a source of hard-to-debug errors.
To discuss next interim

Related discussion:
text: The following example shows a case where "example.com" has a server running on port 443, with an alternate port of 8443 for QUIC. <del> 6.1.3. </del> <ins> 6.1.4. </ins> The following examples of Endpoints show common usage patterns.
Code change:
Explain the different use-cases on specifying interfaces to
There's something obvious I'm not seeing: if I want to specify a multicast or link-local address for an endpoint, why not simply specify that address? What's the use of adding the interface into it? Some addresses will inherently limit interfaces; I thought interface preference was about preferring wifi to 4G, etc.
Like, in section 6.1.1:
Multicast groups can be scoped (see RFC7346), thus, may only be available on certain interfaces or even have different meanings based on the interface. So for Interface- and Link-Local scope, specifying the interface is strictly required. For others use cases (like coping with non-unique use of RFC1918 addresses) this may also be helpful.
Why does the API have both the ability to say LocalSpecifier.WithInterface and to set interface requirements on TransportProperties? Why not just keep the latter and remove the former?
There's history here: LocalSpecifier.WithInterface predates explicitly setting the interface name in interface requirements. There might be reasons to keep this: LocalSpecifier is more likely to show up in application UI than in transport properties. Any text proposed to keep both would need to have an unambiguous way to resolve conflicts between the two. This might be a source of hard-to-debug errors.
To discuss next interim

Related discussion:
text: Specify a Local Endpoint using a STUN server: <del> 6.1.4. </del> <ins> 6.1.5. </ins> Specify a Local Endpoint using an Any-Source Multicast group to join on a named local interface:
Code change:
Explain the different use-cases on specifying interfaces to
There's something obvious I'm not seeing: if I want to specify a multicast or link-local address for an endpoint, why not simply specify that address? What's the use of adding the interface into it? Some addresses will inherently limit interfaces; I thought interface preference was about preferring wifi to 4G, etc.
Like, in section 6.1.1:
Multicast groups can be scoped (see RFC7346), thus, may only be available on certain interfaces or even have different meanings based on the interface. So for Interface- and Link-Local scope, specifying the interface is strictly required. For others use cases (like coping with non-unique use of RFC1918 addresses) this may also be helpful.
Why does the API have both the ability to say LocalSpecifier.WithInterface and to set interface requirements on TransportProperties? Why not just keep the latter and remove the former?
There's history here: LocalSpecifier.WithInterface predates explicitly setting the interface name in interface requirements. There might be reasons to keep this: LocalSpecifier is more likely to show up in application UI than in transport properties. Any text proposed to keep both would need to have an unambiguous way to resolve conflicts between the two. This might be a source of hard-to-debug errors.
To discuss next interim

Related discussion:
text: specified via Provisioning Domain attributes (see prop-pvd) or another specific property. <ins> Note that this property is not used to specify an interface scope for a particular endpoint. ifspec provides details about how to qualify endpoint candidates on a per-interface basis. </ins> 6.2.12. pvd
Code change:
Sections 4.1 and 4.1.3 introduce to configure an Endpoint Object. The address supplied in examples appears to be an address literal. However, Section 1.1 does not define any types explicitly associated with an internet address -- or could work, but I don't think that's the intent for these APIs, either. Section 3.2.2 does not extend this. It's unclear whether this literal is intended to support IPv6 scoped addresses as described in [RFC4007]. While this RFC describes a textual representation (possibly not in line with the goals of the API), [RFC6874] describes how to represent zone indexes in an address literal. If zone indexes are not intended to be supported, this could be clarified by, when "IPv4 and IPv6 address" is mentioned in section 4.1, also citing [RFC791] and [RFC4007] with the respective address family. If zone indexes are intended to be supported, ambiguity exists around the use of and on a Local Endpoint, where the supplied address has a zone index that does not match the supplied interface. This could be clarified by: Defining type names that represent IPv4 and IPv6 addresses in section 1.1. Specifying the properties of an address literal supported by that type (referencing [RFC791] for IPv4 and both [RFC4007] and [RFC6874] for IPv6). Clarifying in section 4.1 that "IPv4 or IPv6 address" are of the respective type described in section 1.1 when used in or . Clarifying the behavior of zone index and interface choices on a Local Endpoint in a new section 4.1.4. This may tie in to to some extent in that this is unlikely to be discoverable until is called. [RFC791]: URL [RFC4007]: URL [RFC6874]: URL
(note this is in §6.1/6.1.3 post-)
Mention that the %en0 addition to the IPv6 address is equivalent to explicitly setting WithInterface. Also mention that these are implied to be system types for addresses
Looks sane

Related discussion:
text: Interface name (string): <ins> Note that an IPv6 address specified with a scope (e.g. "2001:db8:4920:e29d:a420:7461:7073:0a%en0") is equivalent to "WithIPv6Address" with an unscoped address and "WithInterface " together. </ins> An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a
Code change:
I think there's a need for more discussion and clarity around the restriction that "An Endpoint cannot have multiple identifiers of a same type set." Why not? You effectively are letting the endpoint have (potentially) multiple IP addresses when you create it with an identifier that is a DNS name. This feels like an artificial, inconsistent, restriction given the rest of the document (look at the 3rd paragraph of 6.1).
I think the right thing to do is to delete "An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified. Two separate IP addresses are represented as two Endpoint Objects."; if you agree, please do so.
I don't agree that we should delete this. This has been a quite important point in our experience with the API. To make the system work well, resolution should be handled by the TAPS system. If you want to connect by a hostname, provide the hostname—don't try to cache the addresses (often incorrectly) and just pass the same set of addresses again. Note that this doesn't stop multiple addresses from being added to a preconnection. We have this example: Just, one endpoint is a single identifier. You can pass multiple if you want multiple.
NAME
Does this mean the API can't distinguish a remote endpoint that's known to be a single interface with two IP addresses assigned, which would have to be passed as two objects, from two remote endpoints each with a single interface? There's no way of saying "these two IP addresses are known to be the same remote interface"? If so, does this matter?

Related discussion:
text: the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote <del> Endpoint. </del> <ins> Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </ins> The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a
Code change:
Satisfies
looks good.
Should we hold the addition of this until we have something that depends on it being in the API?
We certainly can, although if we want to use a key as discussed in the WG meeting for the purposes of ICMP validation, having a way to add a key here is nice for removing a bootstrapping step. Hopefully we can get an updated ICMP document out with the API document, and they can reference one another in this way.
Discussed in London, remove this.
accepted

Related discussion:
text: "permitted" (required, boolean): indicates whether or not the Captive Portal is open to the requesting host <del> "hmac-key" (required, string): provides a per-host key that can be used to authenticate messages from the Captive Portal enforcement server </del> "user-portal-url" (required, string): provides the URL of a web portal that can be presented to a user to interact with
Code change:
Satisfies
looks good.
Should we hold the addition of this until we have something that depends on it being in the API?
We certainly can, although if we want to use a key as discussed in the WG meeting for the purposes of ICMP validation, having a way to add a key here is nice for removing a bootstrapping step. Hopefully we can get an updated ICMP document out with the API document, and they can reference one another in this way.
Discussed in London, remove this.
accepted

Related discussion:
text: "bytes-remaining" (optional, integer): indicates the number of bytes left, after which the host will be in a captive state <del> Note that the use of the hmac-key is not defined in this document, but is intended for use in the enforcement step of the Captive Portal Architecture. </del> 3.3. To request the Captive Portal JSON content, a host sends an HTTP GET
Code change:
Add key for extending sessions. Implements .
I want to be clear that there is no extend-session API here. It's just an indication that the user could do that somehow, in a browser.
NAME correct, there's no specific API to do so. It just indicates if there's a possibility of the user doing so. Future mechanisms for doing so automatically are left for the future =)
Boolean value to add. Suggested names have been and .
LGTM

Related discussion:
text: it wishes to share with the user (e.g., store info, maps, flight status, or entertainment). <ins> "can-extend-session" (optional, boolean): indicates that the URL specified as "user-portal-url" allows the user to extend a session once the client is no longer in a state of captivity.  This provides a hint that a client system can suggest accessing the portal URL to the user when the session is near its limit in terms of time or bytes. </ins> "seconds-remaining" (optional, integer): indicates the number of seconds remaining, after which the client will be placed into a captive state.  The API server SHOULD include this value if the
Code change:
This PR removes the manifest section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading, which does not need a manifest. This and other removed sections can be defined in other documents in the future. Adapted from URL
We might want to make sure the impact of removing manifest section from the bundle format on the chromium. NAME NAME Does Chrome have any usages of manifest section? It seems doesn't use it, however, I am wondering whether there is existing use case for that, I am not aware of.
I never really understood the motivation of this section, since the primary URL response can contain a header pointing to the manifest.
Imagine the situation of application distribution, it is very useful to have a manifest section. For example, we can display the application icon without parsing the HTML of the primary URL. But I agree that the manifest section can be outside the scope of the "core" bundle specification. So removing it from the core spec looks good to me.
LGTM (just for record). Thanks for working on this.

Related discussion:
text: ""index"" (index-section) <del> ""manifest"" (manifest-section) </del> ""critical"" (critical-section) ""responses"" (responses-section)
Code change:
This PR removes the manifest section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading, which does not need a manifest. This and other removed sections can be defined in other documents in the future. Adapted from URL
We might want to make sure the impact of removing manifest section from the bundle format on the chromium. NAME NAME Does Chrome have any usages of manifest section? It seems doesn't use it, however, I am wondering whether there is existing use case for that, I am not aware of.
I never really understood the motivation of this section, since the primary URL response can contain a header pointing to the manifest.
Imagine the situation of application distribution, it is very useful to have a manifest section. For example, we can display the application icon without parsing the HTML of the primary URL. But I agree that the manifest section can be outside the scope of the "core" bundle specification. So removing it from the core spec looks good to me.
LGTM (just for record). Thanks for working on this.

Related discussion:
text: 4.2.2. <del> The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. The bundle can contain multiple representations at this URL, and the client is expected to content-negotiate for the best one.  For example, a client might select the one matching an "accept" header of "application/manifest+json" (appmanifest) and an "accept-language" header of "es-419". 4.2.3. </del> The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the bundle correctly.  Other sections are assumed to be optional.
Code change:
This PR removes the manifest section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading, which does not need a manifest. This and other removed sections can be defined in other documents in the future. Adapted from URL
We might want to make sure the impact of removing manifest section from the bundle format on the chromium. NAME NAME Does Chrome have any usages of manifest section? It seems doesn't use it, however, I am wondering whether there is existing use case for that, I am not aware of.
I never really understood the motivation of this section, since the primary URL response can contain a header pointing to the manifest.
Imagine the situation of application distribution, it is very useful to have a manifest section. For example, we can display the application icon without parsing the HTML of the primary URL. But I agree that the manifest section can be outside the scope of the "core" bundle specification. So removing it from the core spec looks good to me.
LGTM (just for record). Thanks for working on this.

Related discussion:
text: Do all of: <del> If the bundle's contained URLs (e.g. in the manifest and index) are derived from the request for the bundle, percent-encode [1] (URL) any bytes that are greater than 0x7E or are not URL code points [2] (URL) in these URLs.  It is particularly important to make sure no unescaped nulls (0x00) or angle brackets (0x3C and 0x3E) appear. </del> <ins> If the bundle's contained URLs (e.g. in the index) are derived from the request for the bundle, percent-encode [1] (URL) any bytes that are greater than 0x7E or are not URL code points [2] (URL) in these URLs.  It is particularly important to make sure no unescaped nulls (0x00) or angle brackets (0x3C and 0x3E) appear. </ins> Similarly, if the request headers for any contained resource are based on the headers sent while requesting the bundle, only
Code change:
We never defined what RA was. Do so by expanding it to Router Advertisment in the abstract.
Note: it's still not clear to me whether we need to cite the RA/DHCP/etc RFCs, or whether they're considered 'well-known' enough to be left alone. Or, is that a questdion for the rfc editors?
I'm comfortable with taking DHCP and Router Advertisements as assumed knowledge. Both are on the .
We never define what an 'RA' is, but we use that term in section 4.1. We should consider expanding it to the full term (Router Advertisement). We may also want to add an informative reference to it when we first mention it. Note that we have the same problem with DHCP here -- I'm not sure offhand what the best practice is regarding terms that have fairly wide use, but may not be understood by everyone (and even what that set of terms is).
RA is listed in the abbreviations document: URL but of course "expand on first use" seems like sound editorial practice.

Related discussion:
text: Abstract This document describes a captive portal architecture.  DHCP or <del> Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning </del> <ins> Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning </ins> Domains (PvDs) is described. 1.
Code change:
If we're using an IP as an identifier, dual stack can add complexity. Mention this.
Raised during review that dual-stack is a use-case worth calling out explicitly. Some suggested text: "Further attention should be paid to a device using dual-stack [rfc4213]: it could have both an IPv4 and an IPv6 address at the same time. There could be no properties in common between the two addresses, meaning that some form of mapping solution could be required to form a single identity from the two address."

Related discussion:
text: such cases, it is possible for the components to still uniquely identify the device if they are aware of the port mapping. <del> In some situations, the User Equipment may have multiple IP addresses, while still satisfying all of the recommended properties. This raises some challenges to the components of the network.  For example, if the User Equipment tries to access the network with multiple IP addresses, should the Enforcement Device and API Server treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An </del> <ins> In some situations, the User Equipment may have multiple IP addresses (either IPv4, IPv6 or a dual-stack RFC4213 combination), while still satisfying all of the recommended properties.  This raises some challenges to the components of the network.  For example, if the User Equipment tries to access the network with multiple IP addresses, should the Enforcement Device and API Server treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An </ins> implementation MAY do either.  Attention should be paid to IPv6 and the fact that it is expected for a device to have multiple IPv6 addresses on a single link.  In such cases, identification could be
Code change:
Whether or not the user visits the User Portal is optional: the user could choose not to, or the Captive Portal may not provide one. Clarify that the case presented in the component diagram is the one where the User Portal is present, and where the user chooses to visit it.

Related discussion:
text: 2.6. <del> The following diagram shows the communication between each component. </del> <ins> The following diagram shows the communication between each component in the case where the Captive Network has a User Portal, and the User Equipment chooses to visit the User Portal in response to discovering and interacting with the API Server. </ins> In the diagram:
Code change:
A reviewer pointed out that we used notifying, informing, signalling, and alerting to mean the same thing: sending the Captive Portal Signal. I've chosen to use signal as the verb of choice. The phrasing seems a bit awkward in a few places, so I'm not 100% confident in my choice here.
Alvaro writes, Let's make this consistent across the entire document. Doesn't have to be alert, but should be consistent.
Are we using User Equipment of end-user device?

Related discussion:
text: Captive Portal API Server: Also known as API Server.  A server hosting the Captive Portal API. <del> Captive Portal Signal: A notification from the network used to inform the User Equipment that the state of its captivity could have </del> <ins> Captive Portal Signal: A notification from the network used to signal to the User Equipment that the state of its captivity could have </ins> changed. Captive Portal Signaling Protocol: Also known as Signaling Protocol.
Code change:
A reviewer pointed out that we used notifying, informing, signalling, and alerting to mean the same thing: sending the Captive Portal Signal. I've chosen to use signal as the verb of choice. The phrasing seems a bit awkward in a few places, so I'm not 100% confident in my choice here.
Alvaro writes, Let's make this consistent across the entire document. Doesn't have to be alert, but should be consistent.
Are we using User Equipment of end-user device?

Related discussion:
text: 7.5. <del> The Captive Portal Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to Captive Portal Signals indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal </del> <ins> The Captive Portal Signal could signal to the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to Captive Portal Signals indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end- user devices MAY allow users to manually control captive portal </ins> interactions, possibly on the granularity of Provisioning Domains.
Code change:
The abstract seems weak. It should mention the problem domain and all of the components. Not sure if it needs to mention PvD at all.
Personally, I think that aside from the PvD mention, which can be removed, the current is mostly OK. Brief is good.

Related discussion:
text: This document describes a captive portal architecture.  Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide <del> the solution.  The role of Provisioning Domains (PvDs) is described. </del> <ins> the solution. </ins> 1.