Subject: [httpwg/http-extensions] Julian's CH feedback (#359)

From: HTTP issue updates <[email-masked]>
Date: Mon, 19 Jun 2017 17:16:59 -0700

http://www.w3.org/mid/[email-masked]

Most of this is editorial, so you can dispose of it as you see fit (although some of it is likely to come back up in IETF LC if not addressed. The exceptions are **bold**; I think we need to give some sort of response to those.

* [ ] Througout: avoid lowercase BCP14 keywords (may->can, should->ought to, ...), or actually invoke the new boilerplate defined in draft-leiba-rfc2119-update.
* [ ] s/headers/header fields/
* [ ] **It's not optimal to mention a draft that for now is work in progress so close to a "MUST", even with "optionally" sprinkled in. My recommendation continues to move all material that refers to the Key header field to an appendix.**
* [ ] s/defines/defines the/
* [ ] We should define "origin" somewhere (and also explain "subresource").
* [ ] Througout: uppercase "header field" in section titles.
* [ ] Isn't that evident because sending the hints is purely OPTIONAL anyway?
* [ ] **Why aren't we using HTTP list syntax here? Also, what does it mean when the field appears more than once?**
* [ ] I would rename this to "CSSVAL" (or something like that) for readability.
* [ ] I would rename this to "HTML5" (or something like that) for readability. 
* [ ] I would rename this to "KEY" (or something like that) for readability. 
* [ ] Finally: no Acknowledgements?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/359

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 26 Jun 2017 13:57:59 -0700

> I would rename this to "CSSVAL" (or something like that) for readability.
>  I would rename this to "HTML5" (or something like that) for readability.
>  I would rename this to "KEY" (or something like that) for readability.

I'm inclined to keep them as is. The CSS spec is CSS2, not CSS values specific, and other names are auto generated -- don't think it's worth overwriting.

>> If the desired resource width is not known at the time of the request
>> or the resource does not have a display width, the Width header field
>> can be omitted. ...
>
> Isn't that evident because sending the hints is purely OPTIONAL anyway?

Yes, you could make that case, but it's there to highlight a non-obvious implementation edge case that most will not consider until much later in implementation.. I think it's worth keeping as is.

>> Save-Data = sd-token *( OWS ";" OWS [sd-token] )
>>      sd-token = token
>
> Why aren't we using HTTP list syntax here? Also, what does it mean when 
> the field appears more than once?

This is a repeat of discussion in https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0688.html + https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0678.html. I've added a callout for repeat fields.

---

Opened https://github.com/httpwg/http-extensions/pull/361. I believe it should address all of the above -- ptal.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/359#issuecomment-311179917