From a06a3d7d6f284725b558173450b18b94c7f5ad58 Mon Sep 17 00:00:00 2001 From: Ilya Grigorik Date: Fri, 24 Feb 2017 09:21:34 -0800 Subject: [PATCH 1/3] mark NETINFO reference as non-normative https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0223.html --- draft-ietf-httpbis-client-hints.md | 34 +++++++++++++++--------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/draft-ietf-httpbis-client-hints.md b/draft-ietf-httpbis-client-hints.md index 8434cf266..483821e91 100644 --- a/draft-ietf-httpbis-client-hints.md +++ b/draft-ietf-httpbis-client-hints.md @@ -30,22 +30,6 @@ normative: RFC7230: RFC7231: RFC7234: - NETINFO: - target: https://w3c.github.io/netinfo/ - title: "Network Information API" - author: - - - ins: M. Cáceres - name: Marcos Cáceres - organization: Mozilla Corporation - - - ins: F.J. Moreno - name: Fernando Jiménez Moreno - organization: Telefonica - - - ins: I. Grigorik - name: Ilya Grigorik - organization: Google W3C.REC-html5-20141028: W3C.CR-css-values-3-20160929: CSS2: @@ -67,6 +51,22 @@ normative: informative: RFC6265: I-D.ietf-httpbis-key: + NETINFO: + target: https://w3c.github.io/netinfo/ + title: "Network Information API" + author: + - + ins: M. Cáceres + name: Marcos Cáceres + organization: Mozilla Corporation + - + ins: F.J. Moreno + name: Fernando Jiménez Moreno + organization: Telefonica + - + ins: I. Grigorik + name: Ilya Grigorik + organization: Google --- abstract @@ -233,7 +233,7 @@ If Viewport-Width occurs in a message more than once, the last value overrides a # The Downlink Client Hint {#downlink} -The "Downlink" request header field is a number that indicates the client's maximum downlink speed in megabits per second (Mbps), as defined by the "downlinkMax" attribute in the W3C Network Information API ({{NETINFO}}). +The "Downlink" request header field is a number that indicates the client's maximum downlink speed in megabits per second (Mbps). For example, as defined by the "downlinkMax" attribute in the W3C Network Information API ({{NETINFO}}). ~~~ abnf7230 Downlink = 1*DIGIT [ "." 1*DIGIT ] From a2bb64184fce9986ddebf37db1a1a5a8e497a431 Mon Sep 17 00:00:00 2001 From: Ilya Grigorik Date: Fri, 24 Feb 2017 09:34:17 -0800 Subject: [PATCH 2/3] extend guidance for Accept-CH Related discussions in: https://github.com/httpwg/http-extensions/issues/284 https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/thread.html#msg143 --- draft-ietf-httpbis-client-hints.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-client-hints.md b/draft-ietf-httpbis-client-hints.md index 483821e91..84462fcd4 100644 --- a/draft-ietf-httpbis-client-hints.md +++ b/draft-ietf-httpbis-client-hints.md @@ -116,7 +116,7 @@ A Client Hint request header field is a HTTP header field that is used by HTTP c ## Sending Client Hints -Clients control which Client Hint headers and their respective header fields are communicated, based on their default settings, user configuration and/or preferences. The user can be given the choice to enable, disable, or override specific hints. +Clients control which Client Hint headers and their respective header fields are communicated, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to secure contexts or authenticated sessions. Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for efficient content adaption. @@ -130,7 +130,7 @@ Further, depending on the used hint, the server can emit additional response hea ### Advertising Support for Client Hints {#accept-ch} -Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute ({{W3C.REC-html5-20141028}}). +Servers should advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute ({{W3C.REC-html5-20141028}}). ~~~ abnf7230 Accept-CH = #field-name From 1e0c2d272dd5c4829aa6502a8a0e22411b2f0eec Mon Sep 17 00:00:00 2001 From: Ilya Grigorik Date: Sun, 26 Feb 2017 21:39:40 -0800 Subject: [PATCH 3/3] cleanup based on feedback - Remove NetInfo reference - Accept-CH back to 'can' --- draft-ietf-httpbis-client-hints.md | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) diff --git a/draft-ietf-httpbis-client-hints.md b/draft-ietf-httpbis-client-hints.md index 84462fcd4..6b7f6d627 100644 --- a/draft-ietf-httpbis-client-hints.md +++ b/draft-ietf-httpbis-client-hints.md @@ -51,22 +51,6 @@ normative: informative: RFC6265: I-D.ietf-httpbis-key: - NETINFO: - target: https://w3c.github.io/netinfo/ - title: "Network Information API" - author: - - - ins: M. Cáceres - name: Marcos Cáceres - organization: Mozilla Corporation - - - ins: F.J. Moreno - name: Fernando Jiménez Moreno - organization: Telefonica - - - ins: I. Grigorik - name: Ilya Grigorik - organization: Google --- abstract @@ -116,7 +100,7 @@ A Client Hint request header field is a HTTP header field that is used by HTTP c ## Sending Client Hints -Clients control which Client Hint headers and their respective header fields are communicated, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to secure contexts or authenticated sessions. Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. +Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to secure contexts or authenticated sessions. Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for efficient content adaption. @@ -130,7 +114,7 @@ Further, depending on the used hint, the server can emit additional response hea ### Advertising Support for Client Hints {#accept-ch} -Servers should advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute ({{W3C.REC-html5-20141028}}). +Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute ({{W3C.REC-html5-20141028}}). ~~~ abnf7230 Accept-CH = #field-name @@ -233,7 +217,7 @@ If Viewport-Width occurs in a message more than once, the last value overrides a # The Downlink Client Hint {#downlink} -The "Downlink" request header field is a number that indicates the client's maximum downlink speed in megabits per second (Mbps). For example, as defined by the "downlinkMax" attribute in the W3C Network Information API ({{NETINFO}}). +The "Downlink" request header field is a number that indicates the client's maximum downlink speed in megabits per second (Mbps). ~~~ abnf7230 Downlink = 1*DIGIT [ "." 1*DIGIT ]