Original text:
client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. <del> The token is a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on. </del>  8.

Reviewer comments:
only one "on" value is recognized today allow parameters on token Discussion: URL NAME NAME can you please do a quick sanity check?
NAME thanks, updated! getting warmer?
Think so. NAME is the Keeper of the ABNF, though.
NAME NAME thanks. Updated, do you want to do a last sanity check before I merge?
Looks good to me.
I understand that the current method has the save-data aspect of client hints as a simple on/off switch. I wonder, though, about the willingness to consider allowing for some extensibility. Right now, someone saying "save-data=on" is signing up for pretty much anything. Separating acceptance of data saving for different elements, e.g. agreeing to smaller video resources but not lower fidelity audio, seems like it may be useful. I suggest that the working group consider making this an extensible field with "save-date=all" as the default, with semantics matching the current "save-data=on". Then later extensions can be specified for more granular statements.
I think we can already achieve this with current definition: We can define other tokens We can define parameters - e.g. "on;video-only", etc. Changing from "on" to "all" doesn't really change anything. Also, we already have both client and server implementations that are relying on "on". p.s. some background: URL
NAME - any further comment?
I think the parameter method would be quite useful, and if the doc describes that it would be useful. I'm less sanguine about introducing parameters later, but I certainly wouldn't fall on any sharp objects if that were the decision of the WG.
I guess we should clarify that it is extensible and define "on" as one of its recognized values... Does that make sense? I'm sure my ABNF is off.. :)
, Ilya Grigorik EMAIL wrote: regards, Ted
Resolved via .
Is there a reason to use semicolon here instead of the more typical comma? Also, the grammar does seem off: it does not allow whitespace (because the “implied ” rule of RFC 2616 no longer applies), and it uses instead of . Assuming you really want semicolons, I think it should be: (I can file a separate issue if you want)
I wouldn't say comma is "typical" -- it depends a bit on the use case. For instance, alt-svc uses a list of comma-delimited directives, each of which can have semicolon delimited parameters. In any case, if this does not use commas, the spec ought to state what happens when commas turn up in a field value, or if a field occurs multiple times in a messages (this is stated for the other client hints).
That, indeed, was the intent - e.g. "on;video-only". Re, OWS: good catch. Addressed in URL

Revised text:
client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons.  <ins> This document defines the "on" sd-token value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on.  New token and extension token values can only be defined by revisions of this specification. </ins> 8.