for the API that end-user devices query for information about what is required to escape captivity.  DHCP, DHCPv6, and Router- Advertisement options for this purpose are available in RFC7710. <del> Other protocols (such as RADIUS), Provisioning Domains I-D.ietf- intarea-provisioning-domains, or static configuration may also be used.  A device MAY query this API at any time to determine whether the network is holding the device in a captive state. </del>  End-user devices can be notified of captivity with Captive Portal Signals in response to traffic.  This notification should work 2.2.2. <del> I-D.ietf-intarea-provisioning-domains proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for a JSON file containing key-value pairs to be downloaded over HTTPS.  This JSON file would fill the role of the Captive Portal API described in section_api. </del>  The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the HTTPS server. <del> One key-value pair can be used to indicate the network has restricted access, requiring captive portal navigation by a user.  E.g., key="captivePortal" and value=<URI of portal>.  The key-value pair should provide a different result when access is not restricted. E.g., key="captivePortal" and value="". This JSON file is extensible, allowing new key-value pairs to indicate such things as network access expiry time, URI for API access by IOT devices, etc. The PvD server MUST support multiple (repeated) queries from each User Equipment, always returning the current captive portal information.  The User Equipment is expected to make this query upon receiving (and validating) a Captive Portal Signal (see section_signal). </del> 2.3. The purpose of a Captive Portal API is to permit a query of Captive

We were incorrectly describing the behaviour of the capport PvD option. Update the text to better reflect how it will work, and reference the new draft describing that behaviour. This removes most of the section describing the behaviour, since it's now in the new draft. Fixes Issue .
Let's talk about adoption of the capport-pvd draft before we make this sort of change.
NAME , was the capport-pvd draft discussed during IETF 104? I don't see anything in the minutes.
NAME we did not specifically discuss the capport-pvd draft. I think that doesn't need to be in this first core flight of docs. Note we'll be discussing the core PvD doc more in intarea and hopefully will get that out to last call.
NAME Alright. The existing content is still wrong, though. So, to fix this, perhaps we should just remove the references to PvDs in general?
This text incorrectly describes the PvD JSON as the API JSON. This is incorrect. We should also refer to the CAPPORT PvD proposal document which explains this.
anything left for this please?
NAME
Seems fine to me to close
Does PvD mechanism deliver the capport state, or a pointer to the capport API, from which capport state is retrieved?
In IETF101 capport meeting, I think I heard that PvD is not designed for conveying per-UE state. Hence, PvD may provide a URI to the capport API, but not convey the state itself.
NAME is this addressed in in the sense that the referenced doc covers it?
Yes. I think it is.

for the API that end-user devices query for information about what is required to escape captivity.  DHCP, DHCPv6, and Router- Advertisement options for this purpose are available in RFC7710.  <ins> Other protocols (such as RADIUS), Provisioning Domains I- D.pfister-capport-pvd, or static configuration may also be used. A device MAY query this API at any time to determine whether the network is holding the device in a captive state. </ins> End-user devices can be notified of captivity with Captive Portal Signals in response to traffic.  This notification should work 2.2.2.  <ins> Although still a work in progress, I-D.pfister-capport-pvd proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for the JSON-based API described in section_api. </ins> The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the HTTPS server.  2.3. The purpose of a Captive Portal API is to permit a query of Captive


2.2.2. <del> Although still a work in progress, I-D.ietf-intarea-provisioning- domains proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for a JSON file containing key-value pairs to be downloaded over HTTPS.  This JSON file would fill the role of the Captive Portal API described in section_api. </del>  The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the

PvD is almost certainly going to be published first, so remove the lead-in to it in preparation for integrating the full rfc soon.
When the document says: It might be better to just remove the lead-in part, since it appears PvD will be published ahead of this document.

2.2.2.  <ins> I-D.ietf-intarea-provisioning-domains proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for a JSON file containing key-value pairs to be downloaded over HTTPS.  This JSON file would fill the role of the Captive Portal API described in section_api. </ins> The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the


CAPPORT Architecture <del> draft-ietf-capport-architecture-04 </del>  Abstract

Bump the version of the draft in preparation for submission. This version picks up: An editorial change related to pvds A description of what to do when the captive portal URI changes.

CAPPORT Architecture  <ins> draft-ietf-capport-architecture-05 </ins> Abstract


addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs.  4. This section aims to improve understanding by describing a possible

Thanks for doing this! I've left a few minor comments.
Just for transparency. Erik and I discussed this and made a few editorial changes.
thanks, was just trying to work on the changes here
Based on discussion in Singapore, the group decided to recommend (not require) that URLs use names that can be resolved from the public DNS (no split horizon, etc...). The content served from those URLs should also not be dependent on the network path, but instead the URL would include all information necessary to produce the resource.
i remember we were talking about primarily venue URL should be context free however, the architecture doc does not mention the venue URL (only portal URL) which section shall we add this context-free please? (maybe in section_pvd?) shall we also mention this in the api doc?
I think that NAME might want to think about what to include once we have text here. The text can be generic. I would suggest a new Section 3.5 as this relates to identification of UE. That is, you say that information presented in the API - and in particular URLs - need to include identification UE information. In particular, any information that is used from this context should not depend on ambient information, such as the remote address on a connection, as this information might be used by the UE on a different network interface. For example, a user might access venue information URLs from another network. You might also then mention that this might expose the service to spoofing or replay of that information in those cases. This might mean that though the URL might "work", it might not present all options. For instance, payment options might not be offered, or if they are, warnings might be shown that the payment is not for the current connection.
Thanks for doing this. This seems to accurately capture the outcome of the discussion we had.

addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs. <ins> 3.4.3. The URLs provided in the API SHOULD contain all the information necessary to render the resources requested: the resources should not depend on ambient information, such as remote address on the connection.  This is to ensure that the content served from these URLs is correct and meaningful to the User Equipment, even when accessed from a network other than the one that contains the captive portal.  One consequence of this is that URLs provided in the API are expected to be resolved using public DNS. Though a URL might still correctly resolve when the UE makes the request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. URLs could include some means of identifying the User Equipment in the URLs.  However, including unauthenticated User Equipment identifiers in the URL may expose the service to spoofing or replay attacks. </ins> 4. This section aims to improve understanding by describing a possible


2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710.  The CAPPORT architecture </del>  expects this URI to indicate the API described in section_api. Although it is not clear from RFC7710 what protocol should be

Note that this leaves this paragraph intact: That paragraph probably needs to go based on what is in 7710bis now.
And remove some of the stuff that is speculative from SS2.2.1.

2.2.1. A standard for providing a portal URI using DHCP or Router  <ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture </ins> expects this URI to indicate the API described in section_api. Although it is not clear from RFC7710 what protocol should be


2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710.  The CAPPORT architecture </del>  expects this URI to indicate the API described in section_api. <del> Although it is not clear from RFC7710 what protocol should be executed at the specified URI, some readers might have assumed it to be an HTML page, and hence there might be User Equipment assuming a browser should open this URI.  For backwards compatibility, it is RECOMMENDED that the server check the "Accept" field when serving the URI, and serve HTML pages for "text/html" and serve the API for "application/json".  [REVISIT: are these details appropriate?] </del> 2.2.2. Although still a work in progress, I-D.pfister-capport-pvd proposes a Information containing the URI for the JSON-based API described in section_api. <del> The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the HTTPS server. </del> 2.3. The purpose of a Captive Portal API is to permit a query of Captive

This removes some text around discovering URLs with 7710[bis] and PvD. That extra context can be handled by those documents. This builds on .
Looks good
Lgtm
LGTM

2.2.1. A standard for providing a portal URI using DHCP or Router  <ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture </ins> expects this URI to indicate the API described in section_api.  2.2.2. Although still a work in progress, I-D.pfister-capport-pvd proposes a Information containing the URI for the JSON-based API described in section_api.  2.3. The purpose of a Captive Portal API is to permit a query of Captive


Abstract <del> This document aims to document consensus on the CAPPORT architecture. DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </del>  1. The architecture uses the following mechanisms: <del> The architecture attempts to provide privacy, authentication, and safety mechanisms to the extent possible. </del>  1.1. At this time we consider only devices with web browsers, with web applications being the means of satisfying Captive Portal Conditions.  None of the above requirements are mandatory because (a) we do not wish to say users or devices must seek full access to the captive The purpose of a Captive Portal API is to permit a query of Captive Portal state without interrupting the user.  This API thereby removes <del> the need for a device to perform clear-text "canary" HTTP queries to check for response tampering. </del>  The URI of this API will have been provisioned to the User Equipment. (Refer to section_provisioning). This architecture expects the User Equipment to query the API when the User Equipment attaches to the network and multiple times thereafter.  Therefore the API MUST support multiple repeated queries <del> from the same User Equipment, returning the current state of captivity for the equipment. </del>  <del> At minimum the API MUST provide: (1) the state of captivity and (2) a URI for a browser to present the portal application to the user.  The API SHOULD provide evidence to the caller that it supports the present architecture. </del>  When user equipment receives Captive Portal Signals, the user equipment MAY query the API to check the state.  The User Equipment The API MUST be extensible to support future use-cases by allowing extensible information elements. <del> The API MUST use TLS for privacy and server authentication.  The implementation of the API MUST ensure both privacy and integrity of any information provided by or required by it. </del>  This document does not specify the details of the API. 2.4. <del> The Captive Portal Enforcement component restricts network access to User Equipment according to site-specific policy.  Typically User </del>  Equipment is permitted access to a small number of services and is <del> denied general network access until it has performed some action. </del>  The Captive Portal Enforcement component: User Equipment may send traffic to hosts blocked by the captive network prior to the Enforcement device granting it access.  The Enforcement Device rightly blocks or resets these requests.  However, <del> lacking a signal from the Enforcement Device or interaction with the API server, the User Equipment can only guess at whether it is captive.  Consequently, allowing the Enforcement Device to explicitly signal to the User Equipment that the traffic is being blocked may improve the user's experience. </del>  <del> An Enforcement Device may also want to inform the User Equipment of a </del>  pending expiry of its access to the external network, so providing the Enforcement Device the ability to preemptively signal may be desirable. which it points to communicate local network policies. The Captive Portal Enforcement function MAY send Captive Portal <del> Signals when disallowed User Equipment attempts to send to the network.  These signals MUST be rate-limited to a configurable rate. </del>  The signals MUST NOT be sent to the destinations/peers that the User Equipment is restricted from accessing.  The indications are only to

Happy to elaborate on them if the motivation is not clear from the changes, let me know!
Thanks NAME b1dc7ba4e26ab17ed12d8a5a2408fe8063b1177a accepts the suggestion. 509d855e5ddba7dd1c5db58646c85516d0b40987 corrects the mistake I had made, which your question was about.
Looks great. Thanks for the PR!

Abstract  <ins> This document describes a CAPPORT architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </ins> 1. The architecture uses the following mechanisms:  <ins> The architecture attempts to provide confidentiality, authentication, and safety mechanisms to the extent possible. </ins> 1.1. At this time we consider only devices with web browsers, with web applications being the means of satisfying Captive Portal Conditions. <ins> An example interactive User Equipment is a smart phone. The User Equipment: </ins> None of the above requirements are mandatory because (a) we do not wish to say users or devices must seek full access to the captive The purpose of a Captive Portal API is to permit a query of Captive Portal state without interrupting the user.  This API thereby removes  <ins> the need for User Equipment to perform clear-text "canary" HTTP queries to check for response tampering. </ins> The URI of this API will have been provisioned to the User Equipment. (Refer to section_provisioning). This architecture expects the User Equipment to query the API when the User Equipment attaches to the network and multiple times thereafter.  Therefore the API MUST support multiple repeated queries  <ins> from the same User Equipment and return the state of captivity for the equipment. </ins>  <ins> At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server.  The API SHOULD provide evidence to the caller that it supports the present architecture. </ins> When user equipment receives Captive Portal Signals, the user equipment MAY query the API to check the state.  The User Equipment The API MUST be extensible to support future use-cases by allowing extensible information elements.  <ins> The API MUST use TLS to ensure server authentication.  The implementation of the API MUST ensure both confidentiality and integrity of any information provided by or required by it. </ins> This document does not specify the details of the API. 2.4.  <ins> The Captive Portal Enforcement component restrict the network access of User Equipment according to site-specific policy.  Typically User </ins> Equipment is permitted access to a small number of services and is  <ins> denied general network access until it satisfies the Captive Portal Conditions. </ins> The Captive Portal Enforcement component: User Equipment may send traffic to hosts blocked by the captive network prior to the Enforcement device granting it access.  The Enforcement Device rightly blocks or resets these requests.  However,  <ins> in the absence of a signal from the Enforcement Device or interaction with the API server, the User Equipment can only guess at whether it is captive.  Consequently, allowing the Enforcement Device to explicitly signal to the User Equipment that the traffic is being blocked may improve the user's experience. </ins>  <ins> An Enforcement Device may also want to notify the User Equipment of a </ins> pending expiry of its access to the external network, so providing the Enforcement Device the ability to preemptively signal may be desirable. which it points to communicate local network policies. The Captive Portal Enforcement function MAY send Captive Portal  <ins> Signals when User Equipment that has not satisfied the Captive Portal Conditions attempts to send traffic to the network.  These signals MUST be rate-limited to a configurable rate. </ins> The signals MUST NOT be sent to the destinations/peers that the User Equipment is restricted from accessing.  The indications are only to


URLs is correct and meaningful to the User Equipment, even when accessed from a network other than the one that contains the captive portal.  One consequence of this is that URLs provided in the API are <del> expected to be resolved using public DNS. </del>  Though a URL might still correctly resolve when the UE makes the request from a different network, it is possible that some functions

URL provides a definition of "Global DNS" to which we might want to link.
Thanks!

URLs is correct and meaningful to the User Equipment, even when accessed from a network other than the one that contains the captive portal.  One consequence of this is that URLs provided in the API are  <ins> expected to be resolved using public global DNS (as defined in Section 2 of RFC8499). </ins> Though a URL might still correctly resolve when the UE makes the request from a different network, it is possible that some functions


block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic. <del> Problems with captive portal implementations have been described in I-D.nottingham-capport-problem.  [If that document cannot be published, consider putting its best parts into an appendix of this document.] </del> This document standardizes an architecture for implementing captive portals that provides tools for addressing most of those problems. We are guided by these principles:

This was an old, expired submission, unlikely to be revived. The intro provides enough context about what is wrong with captive portals. A problem statement rfc could always be made in the future if necessary, so let's just keep this document focused on the solution.
This paragraph still exists in the document: Problems with captive portal implementations have been described in [I-D.nottingham-capport-problem]. [If that document cannot be published, consider putting its best parts into an appendix of this document.] Maybe pull in sections 3 & 4 from URL ?
NAME I'm fine taking Dave's suggestion to pull in those sections. However, I'm not sure of the best way to attribute the content to that original document/its author. I imagine simply acknowledging Mark is sufficient, but if there is a better practice, please let me know.
Though I am somewhat concerned that it's a lot of text, and could be contentious if we're adding it after last call. For example statements like the one about access only being possible to steal in an insecure wireless network--I'm not convinced that's actually true. Given that this document wasn't really vetted, perhaps it'd be better to just try to summarize in the intro some of the more salient points.
Yes, if we pull in additional text, then I might feel obligated to run another last call. We can ask Mark for permission (not at-mentioning here yet), but I want to understand what this document lacks that Mark's has. My sense is that the text can be just cut, or the problem statement summarized in one of two paragraphs.
Good question. I think the nottingham problem statement was very useful for thinking about the problem and what to avoid. But we do have the guiding principles in the introduction. It would certainly be easier to just drop the mention of it, and focus on what should be vs. what should not be.

block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic.  This document standardizes an architecture for implementing captive portals that provides tools for addressing most of those problems. We are guided by these principles:


Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and <del> the Enforcement Device must invalidate their state related to the </del>  User Equipment. The Enforcement Device needs to be aware of the physical interface, However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor.  Consequently, any solution using <del> the IP address should proactively try to prevent spoofing of the IP </del>  address.  Similarly, if the mapping of IP address to User Equipment <del> is changed, the components of the architecture must remove or update </del>  their mapping to prevent spoofing.  Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API Server to exchange secrets which can be used to validate future interactions. <del> The API must ensure the integrity of this information, as well as its </del>  confidentiality. 7.4.

Does this also need to update the boilerplate text that defines SHOULD, MUST, etc?
forgot to mention that, but the draft is already updated to use 8174 boilerplate
In the paragraph starting at line 633, we say: In particular, " Consequently, any solution using the IP address should proactively" and "the components of the architecture must remove or update their" I think we should either capitalize these two or rephrase them.
Aside from my one comment, lgtm. I don't think the intention of the issue was to rephrase everything that used lowercase, but to make sure that we capitalized everything we needed to.
changed the 2 to capital case
lgtm, thanks.
A scrub for these to determine which are really requirements is a good idea. Also, update SS1.1 to use RFC 8174 boilerplate.
looks OK to me

Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and  <ins> the Enforcement Device MUST invalidate their state related to the </ins> User Equipment. The Enforcement Device needs to be aware of the physical interface, However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor.  Consequently, any solution using  <ins> the IP address SHOULD proactively try to prevent spoofing of the IP </ins> address.  Similarly, if the mapping of IP address to User Equipment  <ins> is changed, the components of the architecture MUST remove or update </ins> their mapping to prevent spoofing.  Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API Server to exchange secrets which can be used to validate future interactions.  <ins> The API MUST ensure the integrity of this information, as well as its </ins> confidentiality. 7.4.


the captive portal web application, and (c) legacy devices must continue to be supported.  2.2. Here we discuss candidate mechanisms for provisioning the User

I'll merge this later today when I go over it and submit the new draft then.
NAME Done.
Thanks! IESG here we come.
The CAPPORT API document explains some requirements on deployments to allow certificate validation of servers, specifically in Section 4.1.1. Server Authentication. Last call comments noted that the architecture should have notes that such provisions are needed.
This appears to be the last PR active on the respository. Can we have an updated version of the draft please?Thanks!

the captive portal web application, and (c) legacy devices must continue to be supported. <ins> If User Equipment supports the Captive Portal API, it MUST validate API server TLS certificate (see RFC2818).  An Enforcement device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST NOT proceed with any of the behavior described above. </ins> 2.2. Here we discuss candidate mechanisms for provisioning the User


2.2. Here we discuss candidate mechanisms for provisioning the User <del> Equipment with the URL of the API to query captive portal state and </del>  navigate the portal. 2.2.1. <del> A standard for providing a portal URL using DHCP or Router </del>  Advertisements is described in RFC7710bis.  The CAPPORT architecture <del> expects this URL to indicate the API described in section_api. </del>  2.2.2. Although still a work in progress, I-D.pfister-capport-pvd proposes a mechanism for User Equipment to be provided with PvD Bootstrap <del> Information containing the URL for the JSON-based API described in </del>  section_api. 2.3. the need for User Equipment to perform clear-text "canary" HTTP queries to check for response tampering. <del> The URL of this API will have been provisioned to the User Equipment. </del>  (Refer to section_provisioning). This architecture expects the User Equipment to query the API when the equipment. At minimum, the API MUST provide: (1) the state of captivity and (2) <del> a URL for the Captive Portal Server.  The API SHOULD provide evidence </del>  to the caller that it supports the present architecture. When User Equipment receives Captive Portal Signals, the User 3.4.3. <del> The URLs provided in the API SHOULD contain all the information </del>  necessary to render the resources requested: the resources should not depend on ambient information, such as remote address on the connection.  This is to ensure that the content served from these <del> URLs is correct and meaningful to the User Equipment, even when </del>  accessed from a network other than the one that contains the captive <del> portal.  One consequence of this is that URLs provided in the API are </del>  expected to be resolved using public global DNS (as defined in Section 2 of RFC8499). <del> Though a URL might still correctly resolve when the UE makes the </del>  request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. <del> URLs could include some means of identifying the User Equipment in the URLs.  However, including unauthenticated User Equipment identifiers in the URL may expose the service to spoofing or replay </del>  attacks. 4. 4.3. <del> A different Captive Portal API URL could be returned in the following </del>  cases: <del> Whenever a new Portal URL is received by end User Equipment, it SHOULD discard the old URL and use the new one for future requests to </del>  the API. 5. Architecture RFC7556 provides some discussion on authenticating an operator. <del> Given that a user chooses to visit a Captive Portal URL, the URL </del>  location SHOULD be securely provided to the user's device.  E.g., the DHCPv6 AUTH option can sign this information.

This replaces any 'URL' terminology with 'URI'. It also adds an informative reference to RFC 3986 , as suggested. Fixes issue
Multiple reviewers have suggested that we use URI instead of URL. I think we should make this change, and add the informative reference.

2.2. Here we discuss candidate mechanisms for provisioning the User  <ins> Equipment with the URI of the API to query captive portal state and </ins> navigate the portal. 2.2.1.  <ins> A standard for providing a portal URI using DHCP or Router </ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture  <ins> expects this URI to indicate the API described in section_api. </ins> 2.2.2. Although still a work in progress, I-D.pfister-capport-pvd proposes a mechanism for User Equipment to be provided with PvD Bootstrap  <ins> Information containing the URI for the JSON-based API described in </ins> section_api. 2.3. the need for User Equipment to perform clear-text "canary" HTTP queries to check for response tampering.  <ins> The URI of this API will have been provisioned to the User Equipment. </ins> (Refer to section_provisioning). This architecture expects the User Equipment to query the API when the equipment. At minimum, the API MUST provide: (1) the state of captivity and (2)  <ins> a URI for the Captive Portal Server.  The API SHOULD provide evidence </ins> to the caller that it supports the present architecture. When User Equipment receives Captive Portal Signals, the User 3.4.3.  <ins> The URIs provided in the API SHOULD contain all the information </ins> necessary to render the resources requested: the resources should not depend on ambient information, such as remote address on the connection.  This is to ensure that the content served from these  <ins> URIs is correct and meaningful to the User Equipment, even when </ins> accessed from a network other than the one that contains the captive  <ins> portal.  One consequence of this is that URIs provided in the API are </ins> expected to be resolved using public global DNS (as defined in Section 2 of RFC8499).  <ins> Though a URI might still correctly resolve when the UE makes the </ins> request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection.  <ins> URIs could include some means of identifying the User Equipment in the URIs.  However, including unauthenticated User Equipment identifiers in the URI may expose the service to spoofing or replay </ins> attacks. 4. 4.3.  <ins> A different Captive Portal API URI could be returned in the following </ins> cases:  <ins> Whenever a new Portal URI is received by end User Equipment, it SHOULD discard the old URI and use the new one for future requests to </ins> the API. 5. Architecture RFC7556 provides some discussion on authenticating an operator.  <ins> Given that a user chooses to visit a Captive Portal URI, the URI </ins> location SHOULD be securely provided to the user's device.  E.g., the DHCPv6 AUTH option can sign this information.


3.3. <del> To evaluate whether an identifier is appropriate, one should consider every recommended property from the perspective of interactions among the components in the architecture.  When comparing identifiers, choose the one which best satisfies all of the recommended properties.  The architecture does not provide an exact measure of how well an identifier satisfies a given property; care should be taken in performing the evaluation. </del>  3.4. <del> This section provides some examples of identifiers, along with some evaluation of whether they are good identifiers.  The list of identifiers is not exhaustive.  Other identifiers may be used.  An important point to note is that whether the identifiers are good depends heavily on the capabilities of the components and where in the network the components exist. </del>  3.4.1. The physical interface by which the User Equipment is attached to the network can be used to identify the User Equipment.  This identifier <del> has the property of being extremely difficult to spoof: the User </del>  Equipment is unaware of the property; one User Equipment cannot manipulate its interactions to appear as though it is another. Further, if only a single User Equipment is attached to a given physical interface, then the identifier will be unique.  If multiple User Equipment is attached to the network on the same physical <del> interface, then this property is not appropriate. </del>  Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and 3.4.2. <del> A natural identifier to consider is the IP address of the User </del>  Equipment.  At any given time, no device on the network can have the same IP address without causing the network to malfunction, so it is appropriate from the perspective of uniqueness.

This rephrases the "Evaluating an Identifier" section (3.3) to refer to identifier types, rather than identifiers. We now draw the distinction between the type of an identifier, and an identifier itself, to avoid ambiguity. Fixes Issue
I'd appreciate it if a reviewer could go over the surrounding text to make sure the distinction is obvious, and we're not misusing the 'type' term.
A reviewer writes, I think we should rewrite this section to be about evaluating types of identifiers or sources of identifiers.
Agreed. It's ambiguous as to whether we're describe how to evaluate equals , or whether we're talking about the types (ip vs ethernet)
Not yet sure this is is all that's needed, but on its own it's clarifying I think.

3.3.  <ins> To evaluate whether a type of identifier is appropriate, one should consider every recommended property from the perspective of interactions among the components in the architecture.  When comparing identifier types, choose the one which best satisfies all of the recommended properties.  The architecture does not provide an exact measure of how well an identifier type satisfies a given property; care should be taken in performing the evaluation. </ins> 3.4.  <ins> This section provides some example identifier types, along with some evaluation of whether they are suitable types.  The list of identifier types is not exhaustive.  Other types may be used.  An important point to note is that whether a given identifier type is suitable depends heavily on the capabilities of the components and where in the network the components exist. </ins> 3.4.1. The physical interface by which the User Equipment is attached to the network can be used to identify the User Equipment.  This identifier  <ins> type has the property of being extremely difficult to spoof: the User </ins> Equipment is unaware of the property; one User Equipment cannot manipulate its interactions to appear as though it is another. Further, if only a single User Equipment is attached to a given physical interface, then the identifier will be unique.  If multiple User Equipment is attached to the network on the same physical  <ins> interface, then this type is not appropriate. </ins> Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and 3.4.2.  <ins> A natural identifier type to consider is the IP address of the User </ins> Equipment.  At any given time, no device on the network can have the same IP address without causing the network to malfunction, so it is appropriate from the perspective of uniqueness.


Captive Portal Conditions: site-specific requirements that a user or device must satisfy in order to gain access to the wider network. <del> Captive Portal Enforcement: The network equipment which enforces the traffic restriction. </del>  Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of The User Equipment is the device that a user desires to be attached to a network with full access to all hosts on the network (e.g., to have Internet access).  The User Equipment communication is typically <del> restricted by the Captive Portal Enforcement, described in </del>  section_capport_enforcement, until site-specific requirements have been met. If User Equipment supports the Captive Portal API, it MUST validate the API server's TLS certificate (see RFC2818).  An Enforcement <del> device SHOULD allow access to any services that User Equipment could </del>  need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf- capport-api for more information.  If certificate validation fails, 2.4. <del> The Captive Portal Enforcement component restricts the network access of User Equipment according to site-specific policy.  Typically User </del>  Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal Conditions. <del> The Captive Portal Enforcement component: </del>  2.5. information about the source physical interface (e.g.  a tunnel). The API Server faces a similar problem, implying that it should co- <del> exist with the Enforcement Device, or that the enforcement device </del>  should extend requests to it with the identifying information. 3.4.2. 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 <del> multiple IP addresses, should the enforcement device and API Server </del>  treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An implementation MAY do either.  Attention should be paid to IPv6 and

We were using "Captive Portal Enforcement", "Captive Portal Enforcement Device" and "Enforcement Device", with varying capitilisation, inconsistently throughout the document. Address that by defining the component as "Captive Portal Enforcement Device", and using that term in section headings, and "Enforcement Device" everywhere else. Fixes issue
Looks good to me
Used in different ways: Captive Portal Enforcement, enforcement device, etc.
I think keeping it shorter is likely better. ? Caps to make it clear it's a first class component in the architecture?

Captive Portal Conditions: site-specific requirements that a user or device must satisfy in order to gain access to the wider network.  <ins> Captive Portal Enforcement Device: The network equipment which enforces the traffic restriction.  Also known as Enforcement Device. </ins> Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of The User Equipment is the device that a user desires to be attached to a network with full access to all hosts on the network (e.g., to have Internet access).  The User Equipment communication is typically  <ins> restricted by the Enforcement Device, described in </ins> section_capport_enforcement, until site-specific requirements have been met. If User Equipment supports the Captive Portal API, it MUST validate the API server's TLS certificate (see RFC2818).  An Enforcement  <ins> Device SHOULD allow access to any services that User Equipment could </ins> need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf- capport-api for more information.  If certificate validation fails, 2.4.  <ins> The Enforcement Device component restricts the network access of User Equipment according to site-specific policy.  Typically User </ins> Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal Conditions.  <ins> The Enforcement Device component: </ins> 2.5. information about the source physical interface (e.g.  a tunnel). The API Server faces a similar problem, implying that it should co-  <ins> exist with the Enforcement Device, or that the Enforcement Device </ins> should extend requests to it with the identifying information. 3.4.2. 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  <ins> multiple IP addresses, should the Enforcement Device and API Server </ins> treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An implementation MAY do either.  Attention should be paid to IPv6 and


The entries in the registry are: The values in this registry shall be allocated under "IETF Review" <del> policy for values strictly smaller than 64, under "Specification Required" policy for values 64-223, and under "Private Use" otherwise (see RFC8126 for the definition of relevant policies). </del>  The procedures for requesting values in the Specification Required space are specified in I-D.ietf-tls-iana-registry-updates.

It's been pointed out that one byte may not be sufficient to run experimental compression algorithms without collisions. Expand the space to 2^16 values, and update the IANA considerations section accordingly.
NAME suggested expanding the compression code point from 1 byte to 2.
Do we really want to do that? I can write up a PR, but I don't really see us ever having more than 20 of those... Old compression types took up only one byte; I expect us to have more, because dictionaries, but not much more, because realistically there are only so many codepoints we can deploy.
Since it was mentioned at the meeting I thought I create an issue so it can be discussed. I'm fine closing since I agree we probably don't need this, unless NAME or someone else has a reason for doing this (and we can reopen later if needed).
I suggested expanding this due to the potential future use of dictionaries. I agree we will likely never have more than 20 standardized code points, but 1 byte is a bit low for experimental use without worry of collision. 1 byte is probably enough, but 2 bytes would definitely be enough, and the cost of 1 extra byte seems pretty low to me.
Fixed in .
Added comment, otherwise lgtm.

The entries in the registry are: The values in this registry shall be allocated under "IETF Review"  <ins> policy for values strictly smaller than 256, under "Specification Required" policy for values 256-16383, and under "Experimental Use" otherwise (see RFC8126 for the definition of relevant policies). Experimental Use extensions can be used both on private networks and over the open Internet. </ins> The procedures for requesting values in the Specification Required space are specified in I-D.ietf-tls-iana-registry-updates.


<del> Transport Layer Security (TLS) Certificate Compression </del>  draft-ietf-tls-certificate-compression-latest Abstract <del> In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted. </del>  This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. 1. In order to reduce latency and improve performance it can be useful <del> to reduce the amount of data exchanged during a Transport Layer Security (TLS) handshake. </del>  RFC7924 describes a mechanism that allows a client and a server to avoid transmitting certificates already shared in an earlier

Now that TLS and DTLS are in the RFC editor's list of abbreviations as "common" there's no need to spell out Transport Layer Security anymore.

<ins> TLS Certificate Compression </ins> draft-ietf-tls-certificate-compression-latest Abstract  <ins> In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. </ins> This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. 1. In order to reduce latency and improve performance it can be useful  <ins> to reduce the amount of data exchanged during a TLS handshake. </ins> RFC7924 describes a mechanism that allows a client and a server to avoid transmitting certificates already shared in an earlier


(compress_certificate(27)), which can be used to signal the supported compression formats for the Certificate message to the peer. Whenever it is sent by the client as a ClientHello message extension <del> (I-D.ietf-tls-tls13, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates. </del>  By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use that adopt certificate compression.  Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from <del> intercepting it, that is, TLS version 1.3 I-D.ietf-tls-tls13 and higher. </del>  7. 7.1. Create an entry, compress_certificate(27), in the existing registry <del> for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3" column values being set to "CH, CR", and "Recommended" column being set to "Yes". </del>  7.2. Create an entry, compressed_certificate(25), in the existing registry <del> for HandshakeType (defined in RFC5246). </del>  7.3. over the open Internet. The procedures for requesting values in the Specification Required <del> space are specified in I-D.ietf-tls-iana-registry-updates. </del>

When running idnits, it reports a couple of issues: RFC1950 and RfC7932 are the zlib and brotli RFCs. I'm guessing the way to fix this would to remove the related MUSTs and downgrade the references, though I haven't come up with appropriate wording yet. /cc NAME (any suggestion?)
fixes a couple more errors that are not listed here btw.
Note that downref "nits" can be handled via documented procedures in . In summary, we can identify them in the IETF LC (when we get there) and see who objects to referring to an informative RFC from this draft, which is intended for standards track. For zlib there are a ton of these already and it looks like somebody just didn't update the downref registry (i.e., I suspect there will be no strenuous objections from anybody). For brotli, it's newer but I am not too worried about the uproar. I'd just leave the MUST and the normative references in.
Ok, thanks NAME I'll close this then.

(compress_certificate(27)), which can be used to signal the supported compression formats for the Certificate message to the peer. Whenever it is sent by the client as a ClientHello message extension  <ins> (RFC8446, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (RFC8446, Section 4.3.2), it indicates the support for compressed client certificates. </ins> By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use that adopt certificate compression.  Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from  <ins> intercepting it, that is, TLS version 1.3 RFC8446 and higher. </ins> 7. 7.1. Create an entry, compress_certificate(27), in the existing registry  <ins> for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH, CR", and "Recommended" column being set to "Yes". </ins> 7.2. Create an entry, compressed_certificate(25), in the existing registry  <ins> for HandshakeType (defined in RFC8446). </ins> 7.3. over the open Internet. The procedures for requesting values in the Specification Required  <ins> space are specified in RFC8447. </ins>


the verification have the same security properties as they would have in TLS normally.  Since certificate chains are typically presented on a per-server name or per-user basis, the attacker does not have control over any individual fragments in the Certificate message, meaning that they

Thanks for doing this NAME I ended up being tied up in a bunch of other stuff.
See message on mailing list from NAME for more details: URL
Do we actually have consensus for this requiring a mitigation?
I probably worded the title wrong. I created this just to keep track of the issue.
lgtm

the verification have the same security properties as they would have in TLS normally. <ins> In order for certificate compression to function correctly, the underlying compression algorithm MUST be deterministic and it MUST output the same data that was provided as input by the peer. </ins> Since certificate chains are typically presented on a per-server name or per-user basis, the attacker does not have control over any individual fragments in the Certificate message, meaning that they


certificate chain. This document describes a mechanism that would allow certificates to <del> be compressed during full handshakes. </del>  2. for decompression.  The "extension_data" field of this extension SHALL contain a CertificateCompressionAlgorithms value: <del> There is no ServerHello extension that the server is required to echo back. </del>  4. uncompressed Certificate message and to enforce limits on the message size before performing decompression. <del> The compressed body of the Certificate message, in the same format as it would normally be expressed in.  The compression algorithm </del>  defines how the bytes in the compressed_certificate_message field are converted into the Certificate message. It is possible to define a certificate compression algorithm that uses a pre-shared dictionary to achieve higher compression ratio. <del> This document does not define any such algorithms. </del>  If the received CompressedCertificate message cannot be decompressed, <del> the connection MUST be torn down with the "bad_certificate" alert. </del>  If the format of the Certificate message is altered using the server_certificate_type or client_certificate_type extensions in TLS normally. In order for certificate compression to function correctly, the <del> underlying compression algorithm MUST be deterministic and it MUST output the same data that was provided as input by the peer. </del>  Since certificate chains are typically presented on a per-server name <del> or per-user basis, the attacker does not have control over any individual fragments in the Certificate message, meaning that they cannot leak information about the certificate by modifying the </del>  plaintext. <del> The implementations SHOULD bound the memory usage when decompressing the CompressedCertificate message. </del>  <del> The implementations MUST limit the size of the resulting decompressed </del>  chain to the specified uncompressed length, and they MUST abort the <del> connection if the size exceeds that limit.  TLS framing imposes 16777216 byte limit on the certificate message size, and the implementations MAY impose a limit that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. </del>  6.

Update reference.
Almost, but I think I can accept my own suggestions so I'll just do that and merge.

certificate chain. This document describes a mechanism that would allow certificates to  <ins> be compressed during all handshakes. </ins> 2. for decompression.  The "extension_data" field of this extension SHALL contain a CertificateCompressionAlgorithms value:  <ins> The compress_certificate extension is a unidirectional indication; no corresponding response extension is needed. </ins> 4. uncompressed Certificate message and to enforce limits on the message size before performing decompression.  <ins> The result of applying the indicated compression algorithm to the encoded Certificate message that would have been sent if certificate compression was not in use.  The compression algorithm </ins> defines how the bytes in the compressed_certificate_message field are converted into the Certificate message. It is possible to define a certificate compression algorithm that uses a pre-shared dictionary to achieve higher compression ratio.  <ins> This document does not define any such algorithms, but additional codepoints may be allocated for such use per the policy in registry. </ins> If the received CompressedCertificate message cannot be decompressed,  <ins> the connection MUST be terminated with the "bad_certificate" alert. </ins> If the format of the Certificate message is altered using the server_certificate_type or client_certificate_type extensions in TLS normally. In order for certificate compression to function correctly, the  <ins> underlying compression algorithm MUST output the same data that was provided as input by the peer. </ins> Since certificate chains are typically presented on a per-server name  <ins> or per-user basis, a malicious application does not have control over any individual fragments in the Certificate message, meaning that they cannot leak information about the certificate by modifying the </ins> plaintext.  <ins> Implementations SHOULD bound the memory usage when decompressing the CompressedCertificate message. </ins>  <ins> Implementations MUST limit the size of the resulting decompressed </ins> chain to the specified uncompressed length, and they MUST abort the  <ins> connection if the size of the output of the decompression function exceeds that limit.  TLS framing imposes 16777216 byte limit on the certificate message size, and the implementations MAY impose a limit that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. </ins> 6.


that is lower than that; in both cases, they MUST apply the same limit as if no compression were used.  6. It's been observed that a significant number of middleboxes intercept

LGTM. NAME can you accept NAME suggestion? I can't do that myself as the branch is on a separate repo. Then it's ready to merge I think.

that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. <ins> While the Certificate message in TLS 1.3 is encrypted, third parties can draw inferences from the message length observed on the wire. TLS 1.3 provides a padding mechanism (discussed in Sections 5.4 and E.3 of RFC8446) to counteract such analysis.  Certificate compression alters the length of the Certificate message, and the change in length is dependent on the actual contents of the certificate.  Any padding scheme covering the Certificate message has to address compression within its design, or disable it altogether. </ins> 6. It's been observed that a significant number of middleboxes intercept


6. <del> 6.1. </del>  Create an entry, compress_certificates(TBD), in the existing registry for ExtensionType (defined in RFC5246). <del> 6.2. </del>  Create an entry, compressed_certificate(TBD), in the existing registry for HandshakeType (defined in RFC5246). <del> 6.3. </del>  This document establishes a registry of compression algorithms supported for compressing the Certificate message, titled

I feel like we should provide a somewhat more specific guidance. "Server implementations MAY choose to negotiate certificate compression only in cases when the TLS version is 1.3 or newer"? (SHOULD is also fine, we should probably pick whatever level draft22 compat hacks use)
AFAICT draft22 doesn't use any specific RFC2119 words for the compat mode (it just says "can use" a bunch of times). Also, I think this is somewhat different in that there's no real change between TLSv1.2 and TLSv1.3 for compression (differently from the TLSv1.3 compat mode where the protocol actually slightly changes). So, knowing the risk, it should just be up to the server and the client to decide whether to use compression or not with TLS < 1.3 IMO.
Good point.

6.  <ins> It's been observed that a significant number of middleboxes intercept and try to validate the Certificate message exchanged during a TLS handshake.  This means that middleboxes that don't understand the CompressedCertificate message might misbehave and drop connections that adopt certificate compression. However this is not a problem when using TLS version 1.3 [draft-ietf- tls-tls13] and higher, due to the fact that the Certificate (and thus the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. 7. 7.1. </ins> Create an entry, compress_certificates(TBD), in the existing registry for ExtensionType (defined in RFC5246).  <ins> 7.2. </ins> Create an entry, compressed_certificate(TBD), in the existing registry for HandshakeType (defined in RFC5246).  <ins> 7.3. </ins> This document establishes a registry of compression algorithms supported for compressing the Certificate message, titled


The values in this registry shall be allocated under "IETF Review" policy for values strictly smaller than 64, and under "Specification <del> Required" policy otherwise (see RFC5226 for the definition of </del>  relevant policies).

Addresses .
Just need to swap out RFC5226 with RFC8126.
Fixed by df35ba55dc4ffee1eb616898e044384782817a89, thanks!

The values in this registry shall be allocated under "IETF Review" policy for values strictly smaller than 64, and under "Specification  <ins> Required" policy otherwise (see RFC8126 for the definition of </ins> relevant policies).


3. This document defines a new extension type <del> (compress_certificates(TBD)), which is used by the client and the server to negotiate the use of compression for their certificate chains, as well as the choice of the compression algorithm. By sending the compress_certificates extension, the client indicates to the server the certificate compression algorithms it supports. The "extension_data" field of this extension in the ClientHello SHALL contain a CertificateCompressionAlgorithms value: If the server supports any of the algorithms offered in the ClientHello, it MAY respond with an extension indicating which compression algorithm it chose.  In that case, the "extension_data" SHALL be a CertificateCompressionAlgorithm value corresponding to the chosen algorithm.  If the server has chosen to not use any compression, it MUST NOT send the compress_certificates extension. </del>  4. <del> If a compression algorithm has been negotiated, server and client MAY compress their corresponding Certificate messages and send them in the form of the CompressedCertificate message (replacing the </del>  Certificate message). The CompressedCertificate message is formed as follows:  The length of the Certificate message once it is uncompressed.  If after decompression the specified length does not match the actual length, the party receiving the invalid message MUST abort the defines how the bytes in the compressed_certificate_message field are converted into the Certificate message. <del> A peer is not required to compress their own Certificate messages even if the compress_certficates extension has been negotiated, but MUST be able to decompress a received CompressedCertificate message. If the negotiated compression algorithm is zlib, then the Certificate </del>  message MUST be compressed with the ZLIB compression algorithm, as <del> defined in RFC1950.  If the negotiated compression algorithm is </del>  brotli, the Certificate message MUST be compressed with the Brotli compression algorithm as defined in RFC7932. server_certificate_type extension RFC7250, the resulting altered message is compressed instead. <del> If the server chooses to use the cached_info extension RFC7924 to replace the Certificate message with a hash, it MUST NOT send the compress_certificates extension. </del> 5. After decompression, the Certificate message MUST be processed as if CompressedCertificate message might misbehave and drop connections that adopt certificate compression. <del> However this is not a problem when using TLS version 1.3 [draft-ietf- tls-tls13] and higher, due to the fact that the Certificate (and thus </del>  the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. 7.1. <del> Create an entry, compress_certificates(TBD), in the existing registry for ExtensionType (defined in RFC5246). </del>  7.2.

This allows for stateless parsers to easily understand the contents of the message without having to keep track of the handshake state. This also decouples client and server compression parameters, allowing compression being negotiated in only one direction.
LGTM, added just a couple of small nits.
Looks good to me.

3. This document defines a new extension type  <ins> (compress_certificate(TBD)), which can be used to signal the supported compression formats for the Certificate message to the peer.  Whenever it is sent by the client as a ClientHello message extension (RFC5246, Section 7.4.1.4), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates.  Note that CertificateRequest messages are not supported by TLS versions prior to 1.3. By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use for decompression.  The "extension_data" field of this extension SHALL contain a CertificateCompressionAlgorithms value: There is no ServerHello extension that the server is required to echo back. </ins> 4.  <ins> If the peer has indicated that it supports compression, server and client MAY compress their corresponding Certificate messages and send them in the form of the CompressedCertificate message (replacing the </ins> Certificate message). The CompressedCertificate message is formed as follows: <ins> The algorithm used to compress the certificate.  The algorithm MUST be one of the algorithms listed in the peer's compress_certificate message. </ins> The length of the Certificate message once it is uncompressed.  If after decompression the specified length does not match the actual length, the party receiving the invalid message MUST abort the defines how the bytes in the compressed_certificate_message field are converted into the Certificate message.  <ins> If the specified compression algorithm is zlib, then the Certificate </ins> message MUST be compressed with the ZLIB compression algorithm, as  <ins> defined in RFC1950.  If the specified compression algorithm is </ins> brotli, the Certificate message MUST be compressed with the Brotli compression algorithm as defined in RFC7932. server_certificate_type extension RFC7250, the resulting altered message is compressed instead.  5. After decompression, the Certificate message MUST be processed as if CompressedCertificate message might misbehave and drop connections that adopt certificate compression.  <ins> However this is not a problem when using TLS version 1.3 I-D.ietf- tls-tls13 and higher, due to the fact that the Certificate (and thus </ins> the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. 7.1.  <ins> Create an entry, compress_certificate(TBD), in the existing registry for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3" column values being set to "CH, CR". </ins> 7.2.


3.  This document defines a new extension type (compress_certificate(TBD)), which can be used to signal the supported compression formats for the Certificate message to the peer.  Whenever it is sent by the client as a ClientHello message <del> extension (RFC5246, Section 7.4.1.4), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates.  Note that CertificateRequest messages are not supported by TLS versions prior to 1.3. </del>  By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use and try to validate the Certificate message exchanged during a TLS handshake.  This means that middleboxes that don't understand the CompressedCertificate message might misbehave and drop connections <del> that adopt certificate compression. However this is not a problem when using TLS version 1.3 I-D.ietf- tls-tls13 and higher, due to the fact that the Certificate (and thus the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. </del>  7.

We already had the understanding that no one will attempt to deploy the extension for TLS 1.2 and earlier, since it would be plagued with middlebox compatibility issues that TLS 1.3 already faces. However, it was left as supported because there was no cost to supporting it. On the list, David Benjamin has pointed out that: clients have no way to ask for "compress only in TLS 1.3" policy, meaning that they have to assume that a TLS 1.2 connection could attempt to use this extension; clients have to support certificate compression in TLS 1.2 as a result. This adds complexity for no reason, and the problem is easily solved by restricting the extension to 1.3 or higher.
:+1: LGTM

3. <ins> This extension is only supported with TLS 1.3 and newer; if TLS 1.2 or earlier is negotiated, the peers MUST ignore this extension. </ins> This document defines a new extension type (compress_certificate(TBD)), which can be used to signal the supported compression formats for the Certificate message to the peer.  Whenever it is sent by the client as a ClientHello message  <ins> extension (I-D.ietf-tls-tls13, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates. </ins> By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use and try to validate the Certificate message exchanged during a TLS handshake.  This means that middleboxes that don't understand the CompressedCertificate message might misbehave and drop connections  <ins> that adopt certificate compression.  Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from intercepting it, that is, TLS version 1.3 I-D.ietf-tls-tls13 and higher. </ins> 7.


to-machine communication across networks of constrained devices. CoAP uses a request/response model where clients make requests to servers in order to request actions on resources.  Depending on the <del> situation the same device may act either as a server or a client. </del>  One important class of constrained devices includes devices that are intended to run for years from a small battery, or by scavenging connecting to a device from the Internet unless the connection was initiated by the device. <del> This document specifies the means for nodes with limited reachability to communicate using simple extensions to CoAP.  The extensions enable publish-subscribe communication using a Broker node that enables store-and-forward messaging between two or more nodes. Furthermore the extensions facilitate many-to-many communication using CoAP. </del>  2. indicated by a link-format content-format.  Sub-topics are also topics and may have their own sub-topics, forming a tree structure of unique paths that is implemented using URIs.  The full URI of a topic <del> includes a schems and authority for the Broker, for example </del>  "coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700". 3.5. If the Broker is unable to serve a certain client that is sending publish messages too fast, the Broker SHOULD respond with Response <del> Code 4.29, "Too Many Requests" I-D.keranen-core-too-many-reqs and set </del>  the Max-Age Option to indicate the number of seconds after which the client can retry.  The Broker MAY stop creating notifications from the publish messages from this client and to this topic for the

This mechanism is also useful for cases where the pub/sub paradigm instead of classic req/resp is desired (one-to-many, many-to-one, many-to-many communications, etc.).

to-machine communication across networks of constrained devices. CoAP uses a request/response model where clients make requests to servers in order to request actions on resources.  Depending on the  <ins> situation the same device may act either as a server, a client, or both. </ins> One important class of constrained devices includes devices that are intended to run for years from a small battery, or by scavenging connecting to a device from the Internet unless the connection was initiated by the device.  <ins> For some applications the client/server and request/response communication model is not optimal but publish-subscribe communication with potentially many senders and/or receivers and communication via topics rather than directly with endpoints may fit better. This document specifies simple extensions to CoAP for enabling publish-subscribe communication using a Broker node that enables store-and-forward messaging between two or more nodes.  This model facilitates communication of nodes with limited reachability, enables simple many-to-many communication, and eases integration with other publish-subscribe systems. </ins> 2. indicated by a link-format content-format.  Sub-topics are also topics and may have their own sub-topics, forming a tree structure of unique paths that is implemented using URIs.  The full URI of a topic  <ins> includes a scheme and authority for the Broker, for example </ins> "coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700". 3.5. If the Broker is unable to serve a certain client that is sending publish messages too fast, the Broker SHOULD respond with Response  <ins> Code 4.29, "Too Many Requests" I-D.ietf-core-too-many-reqs and set </ins> the Max-Age Option to indicate the number of seconds after which the client can retry.  The Broker MAY stop creating notifications from the publish messages from this client and to this topic for the


of the CoRE link format RFC6690.  The target of the link MUST be a URI formatted string.  The client MUST indicate the desired content format for publishes to the topic by using the ct (Content Format) <del> link attribute in the link-format payload.  The client MAY indicate the lifetime of the topic by including the Max-Age option in the CREATE request. Topics may be created as sub-topics of other topics.  A client MAY create a topic with a ct (Content Format) link attribute value which describes a supported serialization of the CoRE link format RFC6690 such as application/link-format (ct=40) or its JSON or CBOR serializations.  If a topic is created which describes a link </del>  serialization, that topic may then have sub-topics created under it as shown in create-sub-fig. A topic creator MUST include exactly one content format link attribute value (ct) in the create payload.  If the Broker does not <del> support the indicated format for both publish and subscribe, it MUST reject the operation with an error code of 4.00 "Bad Request". </del>  There is no default content format.  If no ct is specified, the Broker MUST reject the operation with an error code of 4.00 "Bad upon topic creation.  The lifetime of a topic MUST be refreshed upon create operations with a target of an existing topic. <del> Topic hierarchies can be created by creating parent topics.  A parent topic is created with a POST using ct (Content Format) link attribute value which describes a supported serialization of the CoRE link format RFC6690, such as application/link-format (ct=40) or its JSON or CBOR serializations.  If a topic is created which describes a link serialization, that topic may then have sub-topics created under it as shown in create-sub-fig. </del> The CREATE interface is specified as follows: Client -> Broker

removed duplicate description of hierarchy, added a constraint to allow only one topic to be created at a time, added text to allow additional target attributes in links for created topics

of the CoRE link format RFC6690.  The target of the link MUST be a URI formatted string.  The client MUST indicate the desired content format for publishes to the topic by using the ct (Content Format)  <ins> link attribute in the link-format payload.  Additional link target attributes and relation values may be included in the topic specification link whena topic is created. The client MAY indicate the lifetime of the topic by including the Max-Age option in the CREATE request. Topic hierarchies can be created by creating parent topics.  A parent topic is created with a POST using ct (Content Format) link attribute value which describes a supported serialization of the CoRE link format RFC6690, such as application/link-format (ct=40) or its JSON or CBOR serializations.  If a topic is created which describes a link </ins> serialization, that topic may then have sub-topics created under it as shown in create-sub-fig. A topic creator MUST include exactly one content format link attribute value (ct) in the create payload.  If the Broker does not  <ins> support the indicated format for both publish and subscribe, or if there is more than one "ct" value included in the request, the Broker MUST reject the operation with an error code of 4.00 "Bad Request". Only one topic may be created per request.  If there is more than one link included in a CREATE request, the Broker MUST reject the operation with an erroro code of 4.00 "Bad Request". </ins> There is no default content format.  If no ct is specified, the Broker MUST reject the operation with an error code of 4.00 "Bad upon topic creation.  The lifetime of a topic MUST be refreshed upon create operations with a target of an existing topic.  The CREATE interface is specified as follows: Client -> Broker


basic keep-alive function.  In contrast, Ping and Pong messages are a bidirectional exchange. <del> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the </del>  recipient of a Ping or Pong message MUST ignore elective options it does not understand.

Corrected title for (leaving open while we discuss examples) Corrected version for new since-draft section
It only has examples of Ping and Pong. (It would probably help to have an example of an initial CSM exchange.)
Or perhaps eliminate the examples? I note that RFC7252 does not include Option examples.
I'd rather do the work to include an initial CSM exchange. Just not sure I can get to that tomorrow. (This kind of example is counter-intimidating — after all the verbiage you see that it is all really very simple...)
I'm not sure that it was intimidating although I like counter-intimidating. It was certainly not a source of confusion during WGLC that then required clarification in examples. I worry about simply adding noise. And if pursued further, we should avoid Default-Uri-Host which would leave Max-Message-Size and Block-wise Transfer.
I corrected the title in . I'm won't fixing the suggestion for CSM examples based on my previous comment. This can be revisited if there's any related confusion during subsequent reviews.

basic keep-alive function.  In contrast, Ping and Pong messages are a bidirectional exchange.  <ins> Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical token in response.  Unless there is an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.  As with all Signaling messages, the </ins> recipient of a Ping or Pong message MUST ignore elective options it does not understand.


environment).  ... even if those features stretch the capabilities of such devices. <del> A security solution MUST be implemented to protect CoAP over TCP and MUST be enabled by default.  This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over TCP when appropriate.  Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see I-D.ietf-core-object- security). </del>  7.1. indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port.  8. The security considerations of RFC7252 apply.  For CoAP over

NAME - can you review (don't see you in the Reviewers list)?
Referencing , I have these comments: I feel the text in Section 7 discussing security solutions pertains to both TCP as well as WebSockets, and therefore propose the following amendment: "A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports when appropriate." In addition I have the following suggestion for a new subsection as follows: A CoAP client requesting a resource identified by a “coaps+ws” URI negotiates a secure WebSocket connection to a WebSocket server endpoint, with a “wss" URI. This is described and depicted in section 6.4. As provided by the guidance in Section 4.1 of [RFC6455], the client MUST perform a TLS handshake after opening the connection to the server. The guidance in Section 4.4 of [RFC7925] applies towards mandatory-to-implement TLS functionality for certificates, when a CoAP server exposes resources identified by a “coaps+ws” URI. For the server-side requirements in accepting incoming connections over port 443, guidance given in Section 4.2 of [RFC6455] applies.
Minor. Regarding for the server-side requirements in accepting incoming connections over port 443, guidance given in Section 4.2 of [RFC6455] applies .... RFC6455 actually refers to an HTTPS (HTTP-over-TLS) port in this section:
Thanks Brian, this is ok with me

environment).  ... even if those features stretch the capabilities of such devices.  <ins> A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default.  This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports when appropriate.  Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see I-D.ietf-core-object-security). </ins> 7.1. indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port. <ins> 7.2. A CoAP client requesting a resource identified by a "coaps+ws" URI negotiates a secure WebSocket connection to a WebSocket server endpoint with a "wss" URI.  This is described in coaps-ws-scheme. The client MUST perform a TLS handshake after opening the connection to the server.  The guidance in Section 4.1 of RFC6455 applies.  When a CoAP server exposes resources identified by a "coaps+ws" URI, the guidance in Section 4.4 of RFC7925 applies towards mandatory-to- implement TLS functionality for certificates.  For the server-side requirements in accepting incoming connections over a HTTPS (HTTP- over-TLS) port, the guidance in Section 4.2 of RFC6455 applies. </ins> 8. The security considerations of RFC7252 apply.  For CoAP over


Block-wise Transfer Option.  If a Max-Message-Size Option is indicated with a value that is greater than 1152 (in the same or a different CSM message), the Block-wise Transfer Option also indicates <del> support for BERT (see bert). </del>  4.4.

2/1 Conference call with Signaling authors BERT support can be enabled and then disabled: Max-Message-Size=1153 + Block-wise Transfer => Block-wise on + BERT on Max-Message-Size=1152 => Block-wise on + BERT off This should be noted.

Block-wise Transfer Option.  If a Max-Message-Size Option is indicated with a value that is greater than 1152 (in the same or a different CSM message), the Block-wise Transfer Option also indicates  <ins> support for BERT (see bert).  Subsequently, if the Max-Message-Size Option is indicated with a value equal or less than 1152, BERT support is no longer indicated. </ins> 4.4.


6.5.  The steps are the same as specified in Section 6.4 of RFC7252 with the following changes: If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|. <del> 6.6. </del>  The steps are the same as specified in Section 6.5 of RFC7252 with the following changes:

RFC 7252 section 5.10.1 says: The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. Do we expect this default value to be applicable (and/or useful) for all the cases we are looking at? Maybe keeping Default-Uri-Host is not such a bad idea after all, or maybe we should clarify that this means for, say, a WebSocket server.
We should simply document appropriate defaults for TLS and WebSockets. There is already text for WS:
Regarding this scenario in RFC7252: Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. This is no longer relevant in CoAP over reliable transports. As Klaus noted in the earlier TRAC issue: In CoAP over WebSockets, the virtual server is specified during the WebSocket handshake in the Host header field. The Uri-Host Option is therefore not needed. A client wishing to talk to multiple virtual servers running on the same IP address has to open one WebSocket connection to each virtual server. (Please correct me if I'm wrong.) In CoAP over TLS we have the SNI extension, so I would expect that CoAP over TLS behaves like CoAP over WebSockets: no Uri-Host Option in requests, one connection to each virtual server. For the TLS+SNI case, the default value of the URI-Host is the underlying destination address that's shared across the virtual servers. Further note that the Hostname passed in the TLS SNI extension is not an "IP literal": URL - Literal IPv4 and IPv6 addresses are not permitted in "HostName". would still require our draft to support the URI-Host Option for this case: At the moment, this issue does not appear actionable.

6.5. <ins> CoAP over reliable transports maintains the property from Section 5.10.1 of RFC7252: The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Unless otherwise noted, the default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message.  The default value of the Uri-Port Option is the destination TCP port. For CoAP over TLS, these default values are the same unless Server Name Indication (SNI) RFC6066 is negotiated.  In this case, the default value of the Uri-Host Option in requests from the TLS client to the TLS server is the SNI host. For CoAP over WebSockets, the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server is indicated by the Host header field from the WebSocket handshake. 6.6. </ins> The steps are the same as specified in Section 6.4 of RFC7252 with the following changes: If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|.  <ins> 6.7. </ins> The steps are the same as specified in Section 6.5 of RFC7252 with the following changes:


A sender can also include an elective Custody Option in a Ping message to explicitly request the inclusion of an elective Custody <del> Option in the corresponding Pong message.  The receiver SHOULD delay its Pong message until it finishes processing all the request/ response messages received prior to the Ping message on the current connection. </del>  5.5. BERT block instead. In descriptive usage, a BERT Option is interpreted in the same way as <del> the equivalent Option with SZX == 6, except that the payload is </del>  allowed to contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block). In all these examples, a Block Option is decomposed to indicate the kind of Block Option (1 or 2) followed by a colon, the block number <del> (NUM), more bit (M), and block size exponent (2**(SZX+4)) separated by slashes.  E.g., a Block2 Option value of 33 would be shown as </del>  2:2/0/32), or a Block1 Option value of 59 would be shown as 1:3/1/128. Resources made available via these schemes have no shared identity even if their resource identifiers indicate the same authority (the <del> same host listening to the same TCP port).  They are distinct namespaces and are considered to be distinct origin servers. </del>  The syntax for the URI schemes in this section are specified using Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of 7.6. The steps are the same as specified in Section 6.4 of RFC7252 with <del> the following changes: </del>  <del> If |url| does not have a <scheme> component whose value, when converted to ASCII lowercase, is "coap+tcp", "coaps+tcp", "coap+ws", or "coaps+ws" then fail this algorithm. </del>  <del> If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|. </del>  7.7. The steps are the same as specified in Section 6.5 of RFC7252 with <del> the following changes: </del>  <del> For CoAP over TCP, if the request is secured using TLS, let |url| be the string "coaps+tcp://".  Otherwise, let |url| be the string "coap+tcp://".  For CoAP over WebSockets, if the request is secured using TLS, let |url| be the string "coaps+ws://".  Otherwise, let |url| be the string "coap+ws://". </del>  <del> If the request includes a Uri-Port Option, let |port| be that option's value.  Otherwise, let |port| be the request's destination TCP port. </del>  8.

URL - WGLC review by Esko Dijk • Page 22: "contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)" -> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text -> "contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
NAME - would you review and validate?
The text explains what is allowed with SZX=7 that is not allowed with SZX=6. As correctly noted, 1024 final is already allowed for SZX=6 (as is 1023, 1022, ...), so this is not explicitly listed in the list of additionally allowed cases. Maybe make clearer that this extends what has been allowed before instead of just saying that this is now allowed: s/is allowed/is also allowed/ or s//is additionally allowed/.
That seems like a simpler (if more subtle) edit.

A sender can also include an elective Custody Option in a Ping message to explicitly request the inclusion of an elective Custody  <ins> Option in the corresponding Pong message.  In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/response messages received prior to the Ping message on the current connection. </ins> 5.5. BERT block instead. In descriptive usage, a BERT Option is interpreted in the same way as  <ins> the equivalent Option with SZX == 6, except that the payload is also </ins> allowed to contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block). In all these examples, a Block Option is decomposed to indicate the kind of Block Option (1 or 2) followed by a colon, the block number  <ins> (NUM), more bit (M), and block size (2**(SZX+4)) separated by slashes.  E.g., a Block2 Option value of 33 would be shown as </ins> 2:2/0/32), or a Block1 Option value of 59 would be shown as 1:3/1/128. Resources made available via these schemes have no shared identity even if their resource identifiers indicate the same authority (the  <ins> same host listening to the same TCP port).  They are hosted in distinct namespaces because each URI scheme implies a distinct origin server. </ins> The syntax for the URI schemes in this section are specified using Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of 7.6. The steps are the same as specified in Section 6.4 of RFC7252 with  <ins> minor changes. This step from RFC7252: is updated to: </ins>  <ins> This step from RFC7252: </ins>  <ins> is updated to: </ins> 7.7. The steps are the same as specified in Section 6.5 of RFC7252 with  <ins> minor changes. </ins>  <ins> This step from RFC7252: </ins>  <ins> is updated to: This step from RFC7252: is updated to: </ins> 8.


elective option.  More detailed information SHOULD be included as a diagnostic payload. <del> One reason for an sender to generate an Abort message is a general syntax error in the byte-stream received.  No specific option has been defined for this, as the details of that syntax error are best left to a diagnostic payload. </del>  5.7.

URL - WGLC review by Esko Dijk. In RFC 7252, the Reset message (RST) is also used to deal with certain cases of malformed CoAP messages or incorrect field values. Since the RST message is now removed, I think there should be text on how to deal with these cases. For example in Figure 21 (RFC 7252) the Token value is not recognized which leads to a RST. How should CoAP-over-reliable deal with this case and related cases? Although the draft suggests that Client (if we take the Fig 21 case) could abort the connection, that sounds rather drastic and unnecessary – the client and server need to keep talking to each other typically. Silently ignoring seems better in that case. And in case the receiver of an 'incorrect' message decides not to abort, what should it do instead – anything normative? Related cases for CoAP message receivers are: Token not recognized -> could happen in the Figure 21 use case, silently ignore seems best. Or would there be a reason to notify the response sender that the response is not recognized? (RFC 7252 allows to do this at least.) Token Length TKL is wrong (e.g. length is 9 to 15) -> could be sent by a malicious CoAP endpoint, good reason to abort perhaps Code unrecognized (e.g. 1.xx, 3.xx, 0.31 … ) -> could happen if one of the endpoints supports other/newer CoAP features, perhaps abort, or perhaps silently ignore? Possibly malicious endpoint. Summarizing it seems to me the best to specify a receiver MAY abort the connection and also MUST silently ignore the malformed message. This could be made more explicit in the text.
~
URL My initial instinct would be MUST abort the connection. Can those with early (but shipping) implementations offer any guidance on how this case is currently being handled? What do others think?
The protocol design problem here is that any new feature that is treated harshly by old peers effectively cannot be used. So it is generally better to react with diagnostics to unknown features. Unless there is a way to provide a feature capability indication, which we do have. This then becomes essentially mandatory for any new feature. Clearly MUST abort for syntax violations such as TKL > 8. (If we ever find a use for these field values, they will need a capability indication.) An unrecognized token in a response should never happen. To me this also looks like a MUST abort. (RFC 7252 Figure 21 is about a client losing its state, in which case it would also lose its TCP connection, so that particular case cannot happen on an existing TCP connection.) Grüße, Carsten
Could we indicate that CoAP over reliable aborts the connection for any message format error defined in RFC7252 (plus the unrecognized token case)? URL URL Option Delta: Option Length: URL
Sounds good to me. Message format error = syntax violation Unrecognized token = failure of mandatory matching I’m just trying to think whether there are other “cannot happen”s that need to be on this list. Grüße, Carsten
While you're thinking about other "cannot happens" ... The existing text in the Abort section can be updated to cover this issue in a general way:

elective option.  More detailed information SHOULD be included as a diagnostic payload.  <ins> For CoAP over UDP, messages which contain syntax violations MUST be processed as message format errors.  As described in Sections 4.2 and 4.3 of RFC7252, such messages are rejected by sending a matching Reset message and otherwise ignoring the message. For CoAP over reliable transports, the recipient rejects such messages by sending an Abort message and otherwise ignoring the message.  No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. </ins> 5.7.


reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC7641 for use with these <del> transports. </del>  1. The WebSocket endpoint is identified by a "ws" URI that is composed of the authority part of the "coap+ws" URI and the well-known path <del> "/.well-known/coap" RFC5785.  The path and query parts of a "coap+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP: </del>  The scheme encoding conforms to the encoding rules established for URIs in RFC3986. The WebSocket endpoint is identified by a "wss" URI that is composed of the authority part of the "coaps+ws" URI and the well-known path <del> "/.well-known/coap" RFC5785.  The path and query parts of a "coaps+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. </del>  The scheme encoding conforms to the encoding rules established for URIs in RFC3986.

Doesn't this need an IANA considerations section - URL
We are not creating a registry here; we are extending the semantics of the existing registry created by RFC 5875 to two existing URI schemes. No IANA action required. (We do have an IANA action for registering in that existing registry.)
I was thinking of something like this - URL
Yes -- URL
Doh. For some reason, I got hung up on needing a separate reference for RFC6455, but only the URI suffix is registered. I can appreciate that the lack of a separate draft could be confusing based on the layout of the registry - which will only reference coap-tcp-tls. Sorry for the noise.
: Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" URI, using a well-known URI in the "wss" scheme. However, "wss" is not defined to use well-known URIs, so this is an invalid use ...

reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC7641 for use with these  <ins> transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. </ins> 1. The WebSocket endpoint is identified by a "ws" URI that is composed of the authority part of the "coap+ws" URI and the well-known path  <ins> "/.well-known/coap" RFC5785.  The present specification formally updates RFC6455, extending the well-known URI mechanism defined in RFC5785 to also cover the "ws" URI scheme defined in that document. The path and query parts of a "coap+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP: </ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986. The WebSocket endpoint is identified by a "wss" URI that is composed of the authority part of the "coaps+ws" URI and the well-known path  <ins> "/.well-known/coap" RFC5785.  The present specification formally updates RFC6455, extending the well-known URI mechanism defined in RFC5785 to also cover the "wss" URI scheme defined in that document. The path and query parts of a "coaps+ws" URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP. </ins> The scheme encoding conforms to the encoding rules established for URIs in RFC3986.