This issue is from a related discussion on Apache httpd, which was trying to comply by sending a 504 even though the revalidation error was a 502. That's nuts. The current text for says: However, if a proxy/gateway received a 5xx response while trying to revalidate, this requirement forces it to toss that information and supply a useless 504 instead. That isn't desirable. The entire purpose of this requirement is to make sure that the cache does not respond with its stale entry. Hence, any 5xx code is sufficient.
To fill in more detail, the change in question is this one: URL And covers the wide question of "which 5xx response is returned in low level network failure cases, such as DNS error, connection refused, connection timed out, etc". The commit message referred to RFC2616 14.9.4 Cache Revalidation and Reload Controls, but this seems to be a wider issue.
Yes, that MUST is too strong; I suspect it's there to make the mechanism reliable, not override other potential status codes. Will work on a PR.


Note outstanding question on the issue regarding PUT.
NAME any thoughts about whether we should mention PUT?
I don't think we need to.
I think PUT is already covered in PUT.
Hypothetically, you could be uploading a partial representation of an object, so I'm not sure it's worth prohibiting. However, I've not dealt with any systems that allow partial PUTs. Mostly you PUT (or POST) the blocks as individual resources, then make a final call with the blocklist to assemble the object from the existing blocks. Unless anyone has seen it in action, it's worth indicating it's not common practice. Perhaps a note saying that the behavior is dependent on the method and isn't defined for any known methods?
The essential problem is that it is not interoperable in general for PUT without private agreement between client and server. Furthermore, there is a risk of bypassing content filtering for security, etc. I could see it being usable with a new method.
My understanding has always been that you couldn't have a partial request. We've discussed this extensively before; would need to dig up the references.
(it may have been in discussion of PATCH, which is the proper way to do this)
Proposal: ... to align with the language used in Range.
maybe since this case doesn't matter if the method is unrecognized.
Should we mention PUT's requirement to generate a 400 if C-R is present?
Sorry... I just overlooked this, which is related to the ongoing work with digest NAME My understanding is that with a new method, this could be possible.
Fwiw my minor survey showed that most storage oriented services actually seem to offer some variant of request with Content-Range, see URL
But most of these use PUT, for which this is explicitly called out as "MUST NOT".
I'll propose a RESUME method + Content-Range for that.
I think the simplest possible approach would be PATCH with a payload format that just describes offset, length and payload. No need for a new method.
Which brings us back to the discussion about whether we're defining restrictions or describing usage, doesn't it? Lucas's survey demonstrates that PUT with Content-Range is widely used, even if currently prohibited.
The existing restriction is that PUT means make this payload the current representation. There is no way to remove that restriction without breaking interop for PUT, which pre-existed Content-Range by several years. We are talking about a dozen private implementations of partial PUT versus a billion deployed servers that will gleefully ignore the Content-Range or store it with the new representation (because it starts with Content-*). The only reason this isn't obvious is because almost all Internet-facing HTTP servers disable PUT, so we are left with a few private servers that don't care about Internet standards.
But if we look inside the firewall at internal servers that support WebDAV and other variants of HTTP PUT, they do not support the use of Content-Range to perform a partial PUT. They would be able to support a PATCH method.
I just checked the code and it seems mod_dav has supported partial PUT on flat files since RFC2616.
This is a very big change at the last minute. At a minimum, it needs to be discussed on list. I'm also not very happy documenting a new feature that admits it's not interoperable or backwards-compatible, based upon one implementation in the wild (so far). IMO a much better way of doing this would be to slightly loosen the requirement to generate a 400 when PUT contains a content-range, saying that it can be allowed by an extension or an out-of-band arrangement. Then, if someone wants to, they can create a separate spec for partial PUT.
Well, sure, but that's what the PR says. I don't see how removing the current requirement to generate 400 (which exists to preserve interop) is possible without documenting what should be done instead to preserve interop, even if that happens to be a "Hail Mary" pass more likely to be dropped than caught. I have no idea if this matches any specific implementation. I'd give it around a 50% chance, as opposed to the 10% that I previously assumed. It definitely needs to be discussed on list, but it seems to match the general intent if we allow Content-Range to be used at all. This doesn't prevent anyone from publishing an update in the future. In any case, I decided to propose it now since I did most of the arguing against this feature in the past.
I'm proposing that we just say something like:
In the interest of getting the spec out, I slightly prefer Mark's proposal. That said, if we can get the description of partial PUT in (and that might be possible), I'm ok with that as well.
I think the current implementation landscape suggests us to be open about partial representation in requests (and that's what is relevant WRT ). Which were the compelling reasons for forbidding ?
NAME - see URL
BTW, the Google API also uses a status code to indicate a not-ready-yet error.
They promised to get rid of the 308 years ago; maybe it's just the documentation.
NAME do you still aim for this spec to go to full Internet Standard?
Is this a trick question? Yes, I think we should try. But then, we did add other new things, and also did a lot of re-org.


Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...


I haven't checked the errata yet, but I have to go now and this is worth reviewing.
Maybe end the last paragraph with: "Because of this default, senders in general should mark it as non-cacheable using ...".
sry, accidentally merged early; we still need to deal with the erratum
I don't understand what happened here, but master does not contain the changes that github thinks have been merged.
Yes, I tried to undo my mistake.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
A much belated approval from me. This looks good.


This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.


For
In the abstract: "semantics... including its architecture, terminology..." seems incorrect; suggest "semantics... and its architecture..."
I always find possessive for "HTTP" a little hard to handle.


... full stop.
Also 500f337 (committed instead of PR'd, sorry; if we don't do this that will need to be backed out)


so it's adjacent to the other range-related requirements, rather than separated from them by the authenticated requirements.


refers to a captive portal as a type of intermediary; we should make sure this aligns with the more recent CAPPORT drafts (IIRC current usage of that term is for the origin that the user is redirected to when captured; it's not an intermediary).
It is probably enough to strike "captive portal". "Interception proxy" will do, if "attacker" does not. The term was never something that RFC 7230 relied on and as you say the modern understanding of the term has evolved.


Considerations for new method should mention that the target URI has to be absolute. from URL
+1, thanks for filing!
We currently say: Isn't that sufficiently clear?
It wasn't clear to me because I didn't read the whole doc when I was searching for this information.
It's weird to say this because a URI is always in absolute form (part of what makes it Uniform). Only a reference can be relative, like within the request-target of 1.1 (absolute-path) or anything called a URI-reference. I think what you want to add is a reminder that new method extensions cannot use the host:port or asterisk forms of request target. Note that this only requires a request target in absolute form if the scheme or host:port are necessary to define the target, which they are for CONNECT-UDP.


This MUST is very fuzzy, and obviously isn't testable. Should it just be prose?
Not convinced, but wouldn't object. Maybe "needs to"?
That's what makes the ABNF normative. I don't see a need to change it now.
Sorry, what does the ABNF have to do with this? The issue is the phrase "MUST be able to parse any value of reasonable length", where "reasonable length" is not defined.
It is defined as being reasonable. I have no problem testing that (subjectively). ;-)
I meant the second half.
How about
I like it


There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.


... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.


It occurs to me that if we specify to always be used in conjunction with , and that its semantics are that caches that understand the semantics of the status code can ignore the , all current implementations should already be conferment (if not optimal). Currently, I'm not aware of any cache that implements (because it's new).


They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)


Those changes are editorial.
specifies what to do when it isn't present (use the received time), but not what to do when it doesn't parse. The intuitive thing to do is align, and say that the received time should be used in this situation as well -- but probably not require implementations to replace it if forwarded. I might write some tests...
Okay, I am still waiting on those new glasses. Too much Age. It's fine with me if we interpret an invalid Date as the received time, but that assumes we know the received time when we parse the Date. I think as long as the scope is specific to Caching, we should specify that a cache always record the time received (regardless of Date) and use the received time if the Date field value is invalid.
is used in a number of places in caching, so that modification will be pretty invasive. Why do you think it needs to be restrained to just caching? I suppose it could be specified in semantics as something like 'If the Date field value does not parse, it MAY be replaced with the time the message was received. Caches SHOULD consider the message receipt time as the Date value when it cannot be parsed.'
The "it" in that last sentence has an unclear subject (is it the date, the arrival time, or the cache?), and "consider" -> "use".
The only reason I said it is okay for caching is because we already depend on the cache having a clock and storing time received. It seems reasonable, regardless of role, if the recipient has a clock. But I wasn't suggesting a new requirement.


This is how it works in practice. RFC 6125 is due for an update, I guess. iPAddress subjectAltName has been supported for years and years, but it never managed to capture it properly. This is definitely a big change in that it now outlaws CN-ID. And the definition of IP-ID here is probably overreach, but I don't see how we can avoid that. I don't want to update RFC 6125 here (as much as it needs updating), so making the definition standalone seemed like the right way to handle it.
Discovered via a question NAME asked; it appears that 8aa1781d4fa7d25ab946f6cb1dd1b337435e0a17 made the change to require looking for URI-IDs in the certificate and I don't see any follow-up discussion on that in . However, I've never seen a certificate that offers a URI-ID for an HTTP endpoint. Shouldn't this be a DNS-ID to match current usage? Or perhaps either, with URI-ID preferred, if we believe that's the future?
Er, right, my mistake -- I was trying to describe it as verifying a URI as input, not as looking only at the certificate field for URI-ID. It should either be left unsaid, because it is defined by that RFC, or possibly specify DNS-ID with maybe URI-ID as a backup?
I am not entirely sure that there is need to mention URI-ID (I, for one, don't know of usage of it with HTTP; I barely know of usage of it at all). My understanding is that current practice prefers DNS-ID with a grudging tolerance for CN-ID as fallback (though there are efforts underway to fully deprecate use of CN-ID). Note also that when referencing the RFC 6125 procedures, the protocol document is expected not only to specify what name and type are to be used as input to verification, but also whether wildcard certificate are allowed. It is sometimes also useful to give instruction about what procedures are to be used for revocation checking, though 6125 does leave that explicitly out of its own scope. I am also trying to promote the definition and use of "IPADDR-ID" for the iPAddress SAN, but that's somewhat unrelated.
Do we want to state a position on adoption of URI-ID? If not, then I think we say DNS-ID and MAY consider CN-ID, plus the wildcard language. I'm not aware of anything to reference for IPADDR-ID, and this doesn't seem like the place to define it.
Please don't use CN for anything. Nor rfc822Address nor domainComponent.
I'll be happy to accept any change here that folks generally agree to, preferably in the form of a PR. I already tried just writing it myself and that's what we have now, but it's wrong because I haven't implemented this myself.
Sorry for the late comment; apparently my github notifications aren't set to send me email when a new PR references an issue I'm watching.I'll trust NAME :-)


Without getting into the current politics and history of the term, there are two instances of this term in SEMANTICS that don't appear to contribute substantial value versus using a less loaded choice. : Here, "list" seems sufficient. Perhaps "sites that have been explicitly permitted"?
Good catch. I thought I already checked for those when I replaced man-in-the-middle.
For a direct replacement both safelist and allowlist have seen some uptake.


This isn't a place for equivocation. This could have been MUST except that that isn't good to use here. I considered just "conforms to" as well. That would also work, but that is incompatible with "wishes to" and I was less confident in removing that. I could do "conforms to" with "gateway that interoperates with inbound HTTP servers", but that's a bigger change.


In the definition of the https scheme, the phrase "strong encryption" is used. This implies some sort of judgment. I think that the key is that both client and server need to agree on the adequacy of the protections. Noting that this might be contextual is somewhat obvious at that point, but I thought it might be worth pointing out that what is generally acceptable might change over time.


I know that this is pretty obvious and implied, but maybe it's worth saying.
maybe just s/TE header field/TE request header field/?


Though I think that this text is correct, an HTTP/3 response only ends when the stream is closed, not at the end of the header section. I think that it's not necessary to say this bit anyway.
The related parts were done in so this bit can be applied now as editorial.


The original text here sort of implied that it was enough for an origin server to just send 2xx. That assumed that the request was for the origin server itself and elided a bunch of detail. This is shorter and clearer, I think.
I didn't intend anything here other than a clarification of what was written. I'm mostly guessing what was intended as I don't know what the original text truly intended to say. (I think that it was always possible to use CONNECT with a target of the origin server to do URL But I didn't want to highlight that here; it's a little bit of an odd thing to decide to do and so I wouldn't want to encourage it.)


The first paragraph of the section 5.6.2 on Tokens, which describes delimiters, is misplaced. It should either be the last paragraph in that section or the first paragraph in the parent (Common Rules).
Moving it up would be a bit strange because to the reference to tokens. Moving to the end of the section seems good though.


In : This is probably overly broad considering that the ABNF says (I question the wisdom of including HTAB, but now is not the time to worry about that). Could this be changed to "printable or visible US-ASCII octets, plus SP and HTAB"? (Incidentally, why doesn't the rule use the ABNF rule?)


…levant when some of the acceptable ones are redundant (
However, from item 4 implies otherwise. I think that this only applies if the server wishes to choose between codings, as opposed to apply them all. Compression codings are usually mutually exclusive, but other codings are not necessarily. Splitting this point into a paragraph might be the way to resolve this:
See also URL


I wasn't sure where exactly to include the citation, but the end of the sentence seemed harmless.


The section was talking about server load as well, but it doesn't mention that being a cost of closing connections.
I thought that the assumption was OK-ish: the expectation that clients will retry. That said, I agree that this entire thing could be better. I was looking for a minimal fix.


draft-ietf-httpbis-semantics says in the intro: the multipart/byteranges media type. Is this truly something specific to 1.1? Are there difference in other versions?
Good catch.
okay (editorial)


This text: URL a condition on the conformance requirement that suggests that clients that do know the server will support HTTP/1.1 (or later) can do something else. But it doesn't really address what constraints then apply. I think that this was just to permit the use of the chunked transfer encoding for delimiting the message body, but that does not follow. I think that this might be rephrased as follows:
It reads the same to me, but +1.


A response is incomplete if the TLS connection close was incomplete. Remove text about TLS reuse/resumption, which was very inconsistent. On the first, I removed a case of "partial closure" rather than "incomplete closure". I also linked the incomplete message handling section with the TLS connection closure section.
Apparently I'm not allow to link to after the fact. Sorry for not having done so in the opening comment.
This is okay, but the paragraph before your first change should be rewritten instead. I can fix that later.


I didn't want to make this too disruptive, so I concentrated on the high points. Related to the changes in . Breakdown: integrity is important (existing text) HTTPS provides integrity, but you have to be careful with truncation (includes existing example) HTTP provides no integrity extensions can be used to provide additional protection, including managing the risk of intermediaries messing around (massaging existing text)
talks about message integrity in general terms. The introductory sentence is good, but it then seemingly intermingles several different factors that might be relevant: Accidental corruption of messages in the network. This is not something that applies to HTTPS, but it is relevant for the cleartext variant. The use of intermediaries that might not be trusted not to modify messages. Noting here that this is likely selective as intermediaries need to modify certain parts of messages. Attacks on the protocol, which break down further: a. Attacks on cleartext HTTP, which has no real defense. b. Attacks on TLS, which has good defenses on the whole, though less so with respect to truncation of responses. This is due to the way that HTTP/1.1 allows connection termination (which is under attacker influence) to end a response and the way that TLS in practice is really poor at propagating close_notify in a way that is distinguishable from TCP closure. Overall, I think that this text could be made clearer.


In , Section 2 of -caching is cited. But it would seem like the entire document is a better reference here.


Good point.
I guess all the options are ugly. Should we leave the text wehre ut was and just apply the proposed change in URL ?
Does better belong in -messaging?
Into 6.2?
Seems like the best place, yeah.
NAME : URL
But I don't know what this accomplishes given the paragraph after this one also refers to Transfer-Encoding.This makes sense on its own (with Martin's adjustment). Still not thrilled about having transfer-codings in semantics.Thanks. Fairly simple fix here. I've suggested a tweak for Roy's concern (which I can't make a suggestion before because of GitHub limitations.


is deprecated due to the ubiquity of UTF-8, but the section makes no mention of UTF-8. This might be worth a mention.
It's only used for though and that section already mentions UTF-8. As does the Media Type section. Since is deprecated, perhaps the production should simply be removed and takes directly?
Accept-Charset is deprecated primarily for privacy. It also happens to be less useful now because of utf-8. In contrast, the charset parameter is still used most of the time, mainly to reduce sniffing. We can add something about utf-8, but promoting it too hard will cause other (social) problems.
NAME observation is correct. But then, charset is used in Content-Type as well, just not referenced directly as it is used over there as a regular parameter.
It's not clear to me at least that the production section also applies to .
Syntactically, it does not (because that relies on a more generic syntax for arbitrary parameters). But I agree, this needs cleanup.
Proposal is to remove the ABNF production and to clarify the text (so that it applies to Content-Type as well).


This might be obvious, but the -caching draft never concretely says that a cache key is the information that a cache uses to select a single cached response. It just : "The cache key is comprised of, [...]"
LGTM


A private cache that can be manipulated so that it mistakenly creates a cache entry might not have the reach of a shared cache, but it can still be a problem. Cache poisoning occurs when a cache can be written to by an entity other than the one that the cache would normally recognize as being authorized to write to it. Take the websocket poisoning where a cache misread a websocket stream as HTTP queries and established cached records under arbitrary origins. This would allow for poisoning of entries normally not controlled by the host that was using the websocket. Even though that might have been a single user affected by the poisoning, the effect was serious enough and motivated the inclusion of masking in websocket.
Simple :)


The discussion of seems like it would be more appropriate under 'connections' rather than 'intermediaries.'


After "the server SHOULD respond with a 400 (Bad Request) response" I'd add "and close the connection" as it's not necessarily obvious to everyone.


Regarding the case of multi-valued header, we have this: I'm not seeing anything there which forbids the use of "Content-length: 5,10" anymore. I'd rather emphasize the need for extremely strict parsing of Content-length and keep the duplicate case as the only acceptable exception to this rule, approximately like this: "The Content-Length header field plays a crucial role in message delimitation in HTTP/1.1, and a different error handling between agents was shown to have important consequences in terms of security. As such, it is extremely important that agents do not accept Content-Length header field values that do not strictly comply with the ABNF, that they take care of rejecting values that they are not able to accurately represent internally, and that multiple occurrences of the header field are always checked for, and rejected as invalid. As an exception, if the header field is received multiple times with the same value, or is received as a comma-separated list of identical values, the recipient MAY replace all of them with a single valid Content-Length field containing that decimal value instead of rejecting the message."
Messaging 6.3 says: I think that covers it for HTTP/1.1 (if Transfer-Encoding and Content-Length are both present, that's encouraged to be handled like an error). HTTP/2 says: HTTP/3 says: ... so we could say something in semantics about invalid content-length fields when it's not being used for delimitation, if we wanted to.
Hmmm interesting. I haven't read enough of both parts yet but it's not that bad because I'm in the same situation as someone seeking a solution. I think in the semantics part, there should be an explicit reference to the messaging, for example, "Certain versions of HTTP use Content-Length for message delimitation and may impose stricter rules". This could be sufficient to make the reader check the respective messaging parts. What about the point about being careful about internal representation (i.e. no overflow nor loss of resolution) ? I know I placed it in the middle of the text because it flowed naturally, but this remains a valid item as well.
As a general rule, I think we should not add text to semantics that says some other document has a requirement unless that specifically enlightens the reader regarding the meaning of that protocol element. This is important because the Semantics spec is already "too long" for easy review. If the requirement matters, it will be read by readers of that other document.


Can you please factor the whitespace changes out into a separate PR?
Sorry, my editor did that without my knowledge. I didn't realize the draft was so messy to start with. Will do.
: This is good, but I think that the phrasing here could be more direct. "any semantic implied by the URI itself" - when you read suggests that you might infer something from a URI about what it does. However, I think that this underplays the key point. The point that should be made here is that a resource cannot decide to change the semantics of a method to suit its purposes (I guess unless it is willing to assume all responsibility for doing so, the usual caveat we apply here for things like request logging). Separately, the specific reference to 9.2.1 might be read to imply that safeness is special, but resources don't get to override the semantics of idempotent methods either (or any other well-defined properties of methods). So I would instead phrase this more directly and use the citation as an example only:
NAME can you PR that?
Sure.


is saying something about using From for authentication, but I don't understand it: I think that this could be saying one of two things, maybe the latter: From contains only an unsupported claim about the identity of the generator of the message, so it can't be used for authentication. Including a From value that also contains a secret, such as a password, that could be used to authorize a request is unwise because recipients of the message won't necessarily treat the value as confidential and so the secret might leak. That latter is a bit strange, because an authorization could be bound to the specific request in various ways that might limit these risks. I can't tell because the logical chain between "this is who made the request" and use of the value for authorization isn't very well developed. It might be better to say nothing here instead.
My .02 - I think the intent was more the first -- just a warning that this is not an authentication mechanism to ward off the uninformed and optimistic. Given that this isn't widely used anyway, I don't think the text causes harm; I propose we just leave it as is.
Please, drop everything from "since" onward in that case. The reasoning makes no sense to me and the unsupported recommendation is clear enough.
+1


though I do wonder if HPACK/QPACK needs to be explained as well, since the order in which messages are processed does impact their compression, but not their interpretation.
I would probably say that as the semantics are still stateless, this document probably doesn't need to say anything about that. But that's a weak preference only.
The change looks good to me. That said, it might indeed be good to mention the impact of header compression.
I clarified that this was about semantics. I'm hesitant to talk about header compression, as that's likely to just confuse the matter.
I thought that was already clear. We might need to mention HPACK/QPACK anyway because they are only stateful with regard to the in-transit encoding between peers, and thus deliver stateless messages at the HTTP layer. Or something.
Clarify if the request needs to be the 1st request after a connection is opened.
Is there a reason why you ask? Are there problems when it's not the 1st request?
I'm not aware of any such problem, and for example in haproxy we do support upgrades anywhere.
Just a question I had .. which I feel the spec may want to call it out, either 1st request only or no such restriction.
Nothing in HTTP depends on where a request is placed upon a connection, because it's a stateless protocol. see last paragraph (this is likely to move to soon, which is more appropriate. Should we spell this out more clearly there?
Probably, it never hurts to remind it.
I see the case for proxies to reuse and upgrade an existing connection to the server. Mentioning this will encourage correct server implementations.


I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.


... RFC7230 + RFC7231? This would be noting an editorial change, but okay.
People who are reading other specifications that use the old terminology may have questions.
Also worth putting 'body' in context, since many (e.g., the Fetch API) still use that term.
I could do that directly in Fetch as part of URL I'll have to do some reading though as I've lost the plot a bit.
With or without Roy's addition.


implies a requirement: I would have said instead that HTTP itself doesn't care whether content adheres to this stricture, though some implementations could (or MAY) normalize line endings before sending or after receiving content that uses a media type.
Maybe we can improve the spec by just killing the whole subsection? It refers to the canonical form in MIME, then say we don't neef that, and then makes recommendations for text/* that AFAIU everbody ignores.
This was a huge deal back in 1995-96 and was necessary to bless deployed practice of sending native line endings and expecting the user agents to process them. I guess we can ignore that now? Don't be surprised if JK brings this up in IESG last call.Not seeing anything here worth saving.


Note that if we say it has serious security hazards and we don't mention that in Security Considerations, someone might complain.
PTAL
The text says I'd want to add: "Implementations must be careful about accurately parsing large values or rejecting the messages, as failure to accurately represent the advertised value due to overflows or loss of precision may have serious security consequences." I think it is important to remind, because implementations seem to have progressively shifted towards 64 bit repressentations since 7230, 32-bit ones are still much present, and the risk of desynchronization by advertising more than 4GB is high. By the way, some languages do no provide more than 52 bits of accuracy because they use floats to represent any number... The risk remains low (1 injected byte every 4 PB) but its worth asking to be careful.
Tweaked proposal:
WFM, but I'm still a bit concerned by the fact that we don't say what the receiver should do here, and it doesn't decide to receive too large a chunk :-/ Should we explicitly mention "a recipient must reject the message as invalid if it cannot accurately represent a received chunk size ?"
I think if we say something about that, we should align it with the language for Content-Length:
OK, but then conversion overflows is not the only issue (storing in a float or double is a huge problem, and nowadays sometimes developers don't know, they store it into a "number"). Probably that we should use the same wording for both and slightly adjust the end to say . We can hardly do more but this needs to be said. Using a float with 24-bit mantissa to represent a content-length is already a problem, but in a chunk, 48 MB are enough to miss 3 bytes and desynchronize on a final chunk!


It isn't a normative change because the ABNF already requires port to be present in this form of request. The description is just inconsistent. I also intend to change the reference to 3986 to the right section of this document.
The as used for CONNECT describes the request target as comprising an authority, which consists of an IP or reg-name and, optionally, a port number. The example shows an explicit port of 80. What happens if an explicit port is not included? Does the proxy use the port number associated with the implied protocol (80 if the inbound connection is TCP without TLS, 443 if it is TLS)? Or is it an error? As far as I am aware, a port is always provided in practice. Maybe the answer is to explicitly require that the port number is always present and note that no default port can be supplied in this case as there is no scheme and therefore no associated default port.
cc NAME
NAME +1. This is the most natural outcome based on our established consensus in H2 and H3 that CONNECT requests is not accompanied by a scheme.
It's supposed to be a 400 error.
I verified that Apache mod_proxy will respond with 400 if there is no ":" or if the port is empty or non-numeric, and 403 if the port is not configured for use.
Is this something that needs to be listed as normatice change?


I'm disappointed that RFC 6919 doesn't list "ARE EXPECTED TO".
Time for a bis?
In general, an unknown or new method can be handled by a resource by rejecting the request (with 406 for instance). However, some entities (intermediaries in particular) might be forced to engage with methods that are unknown to them. I couldn't find text in or Section 16.1 on this. However, the draft might benefit from advice on this. There are a few things that might be said, with reference to Section 9, which already says much of this: Intermediaries are expected to forward new methods. This enables the deployment of new methods. New methods might be safe, idempotent, or cacheable. Or they might not be. Actions taken need to consider this possibility and act accordingly. For instance, an intermediary that might be able to automatically retry a request cannot do so for an unknown method, which it does not know whether it is idempotent (9.2) or a cache can't cache a response unless the method is known to be cacheable (9.3).
PTAL. I don't think your second bullet is actionable; that's already clear in 16.1, and intermediaries aren't required to do any of those things.


It's written: Actually I'd rather say "MUST send a version no higher than their own in forwarded messages" (poor wording, I know, maybe someone can propose better). Indeed, if an intermediary receives an HTTP/1.0 request and passes it as HTTP/1.1, the server will wrongly assume that the client can deal with 1.1 (e.g. chunks) and the message may have to be degraded by the intermediary (such as de-chunking and rely on close only). Furthermore, seeing 1.0 for a server is often an indication of very limited (or possibly bogus) client. For example some intermediaries might avoid compressing or caching when facing HTTP/1.0 messages, and as such it's preferable to let such versions be properly advertised in messages that could be considered as potentially unsafe. Maybe a different wording should be "intermediaries... MUST NOT pass a message showing a version they do not support, and MUST make sure the message always conforms to the advertised version".
I agree with Willy: the underlying requirement is that intermediaries accept and send messages only in versions that they understand (unless acting as a tunnel, I guess). The original text basically means that, even if it is phrased in terms of what value is placed in a specific field rather than as the true requirement.
Discussed at Feb 21 interim; should work on a proposal to loosen this somewhat, at least for intermediaries. SHOULD + context?
OK let's try with that.
but see feedback from NAME


Apologies for the lateness, but going through , I think we need to adjust handling of invalid headers: Right now, it's that caches SHOULD treat responses with invalid values as stale. However: No cache tested treats a response with in this manner; all ignore the field. Only Fastly and Firefox treat a response with in this manner; the rest ignore the field. Interestingly, most caches do consider a response with to be stale, except for Apache and Chrome. We specify that the first field line should be used when multiple are present. That's almost universally adhered to (with one deviation by Safari), but we omit multiple values on the same field line from this rule (which are treated as invalids as per above). However: When that line is , all caches reuse the response. When that line is , only Safari and Apache reuse it. This suggests that we could align with current implementations and improve interoperability by: Specifying that invalid fields should be ignored, not make the response stale. This is nearly universal practice. Specifying that the first field value should be used when multiple can be parsed. This is also nearly universal practice.


has a number of caveats about date parsing that aren't mentioned in ; they should be referenced.


That's what this does; the text above already has that effect. It does raise the question of whether we should add CTL to , however. Thoughts?
I believe the proposed text now is somewhat misleading, as it does not mention that CTLs are (and always have been invalid. No, that would be a breaking change.
We still need to rewrite or remove
draft-ietf-httpbis-semantics-latest currently says: However, when I implemented an HTTP/1.1 parsing library that followed this rule, it turned out to broken in the real world. Specifically, users reported that sites using Google Analytics were setting cookies with values containing the ASCII character , which is a control character (URL). And in my investigations at the time, browsers and popular clients like curl all supported this just fine. It would be great if the next round of RFCs could look into this in more detail and define the production in a way that would be acceptable to e.g. the browsers. In my library we currently reject NUL and exotic whitespace (, , , ), on the grounds that those are high-risk for interop bugs and splitting exploits, but allow all other bytes to pass through, including control characters. I don't know if that's the best solution, but in our experience it's at least closer to being real-world compatible than what the RFC draft currently says.
See . URL is what browsers implement, which is slightly more lenient than what you have there. web-platform-tests has tests for that as well.
Was this bug reported to Google Analytics?
To be clear, at Mozilla we found the same thing on routers and such. It's not an isolated incident.
As with the discussion we’re having on-thread about , is it worth us revisiting the language in this specification when we know that non-conformance is widespread?
No, control characters as a set being disallowed in header fields is a relatively new requirement, whereas HTTP has explicitly forbidden CR-only line breaks since 1993 because that is a well-known security hole. Allowing some of the control characters to pass through is not going to decrease the security of valid implementations, whereas allowing CR will only increase the number of insecure browsers subjecting their own users to cache poisoning attacks.
Hmmm - unless I'm missing something they weren't allowed in RFC 2616 either. What's new are the instructions for recipients how to deal with malformed values.
Right, that makes sense, though more strict handling of field values in 7230 was part of the move away from lenient handling for robustness in 2616.
As an HTTP implementer, I'd like to respectfully plead for you to reconsider here, and align the RFC text with the WHAT-WG text for better real-world interoperability. YOLOing together a HTTP/1.1 implementation that's interoperable but insecure is easy. Writing a secure but non-interoperable implementation is pointless, because no-one will use it. Writing a secure AND interoperable implementation is extremely difficult, because it requires that you find the narrowest possible rules that allow only the things that are required to interoperate, and reject everything else, and that's essentially impossible without browser-maker-level visibility into exactly what weird HTTP implementations are out there. The RFCs are an incredible resource for anyone who's trying to build a high-quality implementation, because they contain so much distilled wisdom on where this line is... except for bits like the field-value production, where if you follow the spec you'll get burned and end up having to YOLO something anyway. It's very frustrating to carefully follow the specs, and then be punished for it. And it makes it hard to justify following the spec versus using some YOLO implementation.
We can't align the text. HTTP has always forbidden bare CR as a line break. Almost all deployed implementations rely on that while parsing CR into field values and (CR)LF as line breaks. If we changed that now, all deployed implementations with a cache would have a security hole, instead of just the two evergreen browsers that broke their own parsers and can easily change them back. What servers have been doing (and slowly deploying) is active removal of bare CR in fields when they do character-by-character parsing, just to fix the new browser brokenness. This is a workaround.
With regard to other CTL characters, many are found in the wild, but it would be a stretch to say that they are interoperable when sent in HTTP. Some might be. I don't think we have time to validate such a change.
The WHAT-WG spec text that NAME linked above forbids NUL, CR, and LF inside field values, while allowing everything else. So I'm not suggesting allowing CR. Re: the other control characters: if you can't validate interoperability, then that's a tough position to be in for sure. But surely there's something that would be better than the current text? Currently, all general-usage http clients MUST actively violate the spec. Even if all you can say is "you should definitely disallow NUL/CR/LF and for everything else we're not sure, use your best judgement", then that seems like it would at least be more accurate and helpful than what we have now.
It really would be interesting to see what the effect of converting-to-SP instead of preserving the CTL characters would be. That is, are those characters sent intentionally (I see that this probably is ghe case for G Analytics). Unfortunately, even if we ran an experiment right now, it wouldn't help in this LC.
FWIW URL suggests that the HTTP/2 has a "MUST reject" rule. When we achieve consensus here, the H2bis probably should align.
Yeah, specifically the CTL characters from G Analytics occur in / headers, so it's an opaque value that the server expects to get back. I don't know for sure, but my impression is that someone chose as a "clever" separator character that they knew wouldn't occur inside the values being separated, so converting to SP would probably break it.
I see. Another related question would be: is this something that's specific to cookies?
Note also that the G analytics cookies refer to an old version of custom variables in a library that has been supplanted at least twice (URL --> URL --> URL). It's possible that they were removed because of lacking interop. URL
Discussed in Feb 21 Interim; align with Fetch for hard refusal of characters, strongly caution against CTL (minus NUL) for senders / field definitions. Don't require CTL (minus NUL) to be replaced with space. CR+NUL MUST be converted to space or rejected.


defines Referer and says: There are two other things that I think are relevant to mention here: Referer is often suppressed when the referring resource is "https" at a different origin than the request target. Referer can contain only an origin rather than the referring resource identity. might not be worth citing here as it is probably too specific to browsers, but these other constraints are worth noting. Especially the first as this has real security consequences. Though the text in is excellent as a high-level principle, the steps that are taken to avoid URI leakage are meaningful and very relevant to this section.
Is that "often suppressed" or "always suppressed by good user agents"? I agree that we should update Referer to be consistent with current privacy guidelines.
It is "always suppressed by good user agents, unless the referring origin explicitly asks for it not to be suppressed". These go beyond privacy guidelines into security. Despite the general acknowledgments of the position stated in Section 17.9, there are still resources that leak security-sensitive information through their URL. The notion of a capability URL remains a powerful, and widely used, tool.


When the text suggests that credentials can be automatically applied to all requests made within a protection space, that begs the question: how do I know what requests are in the same protection space? The answer is "well, you don't really". Authentication schemes might define something, but otherwise you are left to guess. This PR says that as directly as I could manage. I considered adding another sentence here that says "In the absence of specific information about the extent of a protection space, clients &MAY; assume that the protection space extent is the origin of the server." I'd like thoughts on whether that is helpful. I think that it might be, as otherwise this isn't really implementable.
Please factor out whitespace changes...
Ugh, it's like picking up toys after children.
Neither of you have comments about saying what the extent of the protection scope is in the absence of information?
I'd rather leave that out.
AFAIU, it depends on the authentication scheme. At the end of the day, we can only document here what we inherited from earlier specs, and what is actually done in practice. If you have information on the latter which helps us making this better, great. Do you?
I proposed maybe adding: Which I believe matches what clients do when they produce credentials and the authentication scheme doesn't define a clear scope. Do you think that helps?
Not sure. What problem are we trying to solve here? Auth scheme definitions that fail to define the protection space? In which case, shouldn't we say something about this in the "Considerations for new schemes" section?
as: This says that it is a parameter, but does it appear on challenges or responses? only establishes that authentication parameters parameterize authentication schemes, there is no mention of how those relate to what is sent. I think that this first problem only requires a mention of WWW-Authenticate and Proxy-Authenticate. The second problem is in : Clients would seem to have no way of knowing whether reuse is likely to be successful. A protection space is defined as the tuple of origin and realm, but there is no acknowledgment that how a protection space might correspond to the URI space is only known to the server. (The next sentence, which I omitted from this quote acknowledges that the client needs special knowledge in order to understand that a protection space might span origins; that's very useful information.) I think that this requires only that the text acknowledge this uncertainty and note that clients could decide to provide authentication information on every request made to the origin, without knowledge of the extent of the protection space. It might also note that particular authentication schemes might define mechanisms that allow clients to decide where to use credentials. RFC 7616 defines , which allows for scoping; RFC 7617 has a section on .
re the first point: we are defining the framework here; whether a scheme uses realm, and how exactly it is used, is out of scope here. What we do is reserve the parameter name "realm", and say what it is for. Could an auth scheme use it in credentials? I believe the answer is "yes".
I think both aspects are up to the authentication scheme in question. Martin, do you feel strongly about this, or can we close?
As you say, it's kinda up for grabs. The main spec isn't very satisfactory though in that it doesn't specify, but doesn't really admit to why that is. Maybe if I can be given a chance to think of some text for this and you can see if you like it.


-- URL This doesn't seem to be enforceable in any way. This isn't really talking about whether the syntax is valid, but about the semantics, so it's easy to disavow knowledge of falsehood (my browser isn't necessary aware that me typing "the sky is pink" is false). I think that it might be better to simply observe that it is contrary to function - and possibly interests - of a sender to generate protocol elements that convey semantics that are incorrect or contrary to the interests of the sender. Normative language implies interoperability failure if it is ever violated, and I don't think that is the case here.
It is enforceable. If a sender communicates a syntactically valid construct that is deliberately misleading, then the recipient's behavior in response will be equally confusing to all parties. We saw exactly that both in the deployment of HTTP/1.1 and in the early deployment of DNT. Both resulted in interop failure, and both failures were only corrected after the standards were enforced by recipients refusing to accept invalid signals.
We might be talking past each other. NAME - could you give us a concrete example that this text is trying to rule out?
Or, for example, P3P, where people deliberately set false and misleading policies so that browsers wouldn't complain. Roy, it's a nice thought, but this is the kind of regulation that's done by law, not architecture.
Both laws and RFCs are defining standards of conduct. The difference with laws is sovereign enforcement, not social versus technical. In any case, this has been true of HTTP implementation (Apache httpd, for example) since 1996. A server will check for compliance based on User-Agent version match and ignore protocol signals that are known to be false or at least unreliably implemented by that sender. Browsers do the same for some servers that deliver default Content-Type settings by mistake. We consider the workarounds to be standards-compliant because of this MUST NOT. And, as I said, we enforce that ALL OF THE TIME.
Discussed at Feb 21 interim; add context to help readers understand why this requirement is here / important. NAME to PR.
Context... ? Then add an example, probably a fictitious one out of deference for the sensitivities in all the truly good examples.
This works very nicely. Thanks Roy. You can point very clearly at the DNT problems, but it's very subtle. And it doesn't detract from the general utility of the text.


I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.


Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.


Make sure that all references to MESSAGING which are not normative are clearly informative. (This ticket is not about those references which right now are indeed normative, see ).


… in that the request must be understood in order to parse and interpret the response.
Well, the simple version is a normative statement in sheep's clothing. Let's just make it normative.
Section 6 claims that . It uses the word "intended", which is an intention that is broadly achieved, with only one exception that I'm aware of at the syntactic level. Having recently implemented message/http, I discovered that some response messages cannot be processed without knowledge of the corresponding request. This is pretty annoying and might be worth noting as a possible exception here. As noted in the response to a HEAD request might include Content-Length, but the content of the response is always empty. At a semantic level, I don't think that any response can be considered without knowledge of the request, so I don't think that self-descriptiveness can possibly apply there. Besides, this section is clearly intended to provide an abstract definition of the syntax and not semantics.
See also


in Section 12.2 uses "representation of the response", which I can't find a definition for. I think this should be "representation data" or "representation data contained in the response".
Much simpler, thanks.This is fine, but "a preferred kind of content" doesn't read well.


... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again


In 3.2.3. authority-form it says Whereas it needs to specifically require host:port, as in the definition of :
does this merit a change log entry?


The spec currently says this about data sent along with a CONNECT request: Is there a demarcation between data "within" a request and data to be sent on the tunnel if it opens successfully? HTTP/2 and HTTP/3 are fairly specific that all DATA frames are data for the tunnel. Do we need to say anything about the client prospectively sending data before the proxy responds?
We should decide what we want to allow. If HTTP/3 is going to send CONNECT data within HTTP/3 frame payloads after (or before) the recipient accepts the CONNECT, then we should specify it differently than how we specified CONNECT in 1.1. I am fine with that.
Hm. Does this imply we special-case 1.1, and require the HTTP/2/3 behaviour for new versions?
I think it is already a special case for 1.1, so that's not a problem.
OK, let me rephrase this then :-). Are we trying to make it consistent for all "new" versions?
Given that CONNECT is specified on a version-by-version basis anyway, I think I'd rephrase it with something like this: CONNECT is one of those weird edges of the protocol where each version will have to respecify its behavior; we don't necessarily need to prescribe what it will be, just make allowances for versions to differ.


The text on doesn't assign any behaviours to roles; it just passively states that http(s) URIs 'are' normalised and compared. This leads to some confusion about what roles are responsible for normalising. E.g., can a server consider and as two different target URIs? I think we all agree on the answer to that, but it isn't clearly stated in the specs AFAICT.
I'm not sure about that example (as a browser would never emit the latter), but they can certainly rely on some of the other variants and have been known to do so.
We currently just point to URL - so "path segment normalization" is something that may or may not happen, depending on who's doing the comparison. My answer would be "a server could do that, but it would be stupid". What's your take?
I agree with your answer, but think we should say something about it -- perhaps going as far as saying a server should/must not do that (as it's not interoperable).
Security is probably a stronger reason not to allow in request targets. Another reason that specific example, as opposed to '+' vs '%20', might be a bad idea.
see also URL
I think the comment is more confusing than the spec. The request target is whatever is provided by the client. If the server responds to the second example target with a 301/302 to the first, then it does consider them to be two different target URIs for the same resource. In practice, that is the best way to respond because it forces the client to change its own copy of the target URI before it makes the "right" request. IIRC, that what we do in Apache httpd. This type of response is not canonicalization -- it's reasonable handling of an unsafe target without breaking the intended request. We might call that responsible handling after the client fails to canonicalize a reference, but keep in mind that a ".." path segment only has meaning for relative references (not references that are already in absolute form). In any case, a client is not required to canonicalize beyond resolving of relative form to absolute form. Some other servers might want to respond with 403 (e.g., an authoring server responding to a link checker). That's okay too.
On the face of it, that conflicts with : Regardless, the question is whether we give any advice about servers considering these to be genuinely separate resources (putting aside corrective actions, as you illustrate), as it's not practically interoperable with most HTTP implementations. Even something in the normalisation section to the effect of:
There's clearly no consensus whether the current relevant specs (RFC 3986 and RFC 7230) allow it or not. This is indeed an obscure case, modern browsers don't request such URIs (not even programatically, from content scripts), neither does cURL with default options. But it should still be settled, for the sake of implementors of web servers and other backend tools, frameworks and authoring tools which help with IA by emitting appropriate server configuration (the question being whether they should allow, possibly with a discouraging message, to create different resources at such URIs, or even assume, given some site not created in them, that they must be the same) and also for defensive coders who believe, as Sir Tim does, that cool URIs don't change, and want to tightly control the set of URIs they respond to with representations of resources and thus admit that the URI is valid – identifies some resource. (I do. Therefore I forbid (default to 404 if they're encountered) trailing slashes, empty path segments, query strings containing only a question mark and so on, except when they are after explicit consideration added to a whitelist.) For all the reasons above I ask you to either declare request with dot segments in targets invalid (some handling may and probably should be defined, but if a client fails to conform to standards by sending malformed requests and gets inconsistent responses, so be it, some bets may be off, the semantics is preserved on the condition of conformance) or specify (MUST level) that the URIs are equivalent (and in thas case it's the servers which are non-conforming if they serve different resources at them). There are also purely practical reasons to do either of the two (as opposed to a SHOULD contemplated in some comments above). Being an uncommon case, it presents a problem for implementations, causing numerous bugs, and confusion (around bugs or otherwise) even among knowledgeable people. Cf. a sample of links resulting from my research of the subject: URL URL URL URL URL URL URL URL
As for the percent-encoding, section 6 of RFC 3986 seems to have the answer that servers aren't allowed to interpret URIs differing only in them as identifying different resources. However, I have 3 more remarks: I wish the MUST requirement were stated explicitly to avoid confusion among implementors, content authors, server administrators and other audiences. The following excerpt seems to erroneously (because absolute examples are present in the following section) limit the whole chapter 6. to relative URI references, thus excluding e.g. the of s (RFC 7230, section 5.3.2.):The difference, introduced in RFC 3986, between URIs (which are always absolute and don't undergo resolution) and URI references (which may be absolute or relative and chapter 5. defines how to resolve them to obtain a URI) is subtle. Extra care to pick the right one each time should be exercised when using the terms. Particularly with normalization. Currently it's not easy to find and definitively interpret text in the standards clarifying whether both are normalized, when, and how normalization rules for them differ.
URL is useful to the extent it provides a way to talk about this. Would it be sane to say that servers MUST do the things described in 6.2.2 of that document? When I'm a client implementor I would be shocked, and my caching software might well break, in dealing with a server that didn't. Section 6.2.3? I think so probably, but it's not nearly as clear and concise as 6.2.2.
NAME I concur, make the language of 6.2.2 and 6.2.3 more precise and with uppercase MUSTs instead of present shoulds. On the other hand, 6.2.4 is bogus in this context, may be moved somewhere and rephrased to be clearly just informative advice. A trailing slash does make a URI semantically different, at least with the and schemes, unless it's immediately preceded by an authority.
Saying servers MUST do anything has the effect of requiring intermediaries to modify URIs on the way through. That's clearly not going to happen, especially given how many different places URIs occur (request target, , , , etc.). OTOH there are some security implications if policy is applied before normalisation. Caches are less efficient as well (not an interop problem, just an efficiency one). Roy, you say 'The request target is whatever is provided by the client.' Do you mean the bytes on the wire (if so, what about h2/h3)? or do you mean after some amount of processing? I think we're just talking about the level of processing that's necessary before the protocol element is consumed (but not necessarily forwarded).
Is there a notion of a server which isn't an intermediary for a given request? If so, how about requiring it only of them? If not, can creators and administrators of resources (people minting URIs for them, either by hand or directing some tool to do it, possibly dynamically) be distinguished as an audience subject to its own set of requirements and have them MUST conform? The advantage of this approach would lie in abstracting from authorities, origins, websites, servers and intermediaries – just the assumptions about the semantics embodied in returned representations and metadata (responses in the case of HTTP) would count as the measure by which to judge conformance. (And they could achieve it with a single server, a server cluster, a CDN, proxies, including non-transparent ones, or whatever else.)
See PR.
Thank you, LGTM mostly. It still does allow minting URIs for different resources which are equal after normalization. It's a SHOULD NOT. I assume that the reluctance to go with MUST NOT results from the concerns raised above, but still it's such a corner case that support for it should IMO be trumped by clarity of semantics and ease of use and implementation. Though users and implementors are, by a MAY, explicitly allowed to conflate such URIs, making some resources unavailable via URI from their perspective, so it's a very strong SHOULD NOT and groups of people wishing to violate it for a good cause (whatever that may be, can you give a use case?) have to ensure there's nothing in either their systems or any intermediaries that would thwart their endeavour by performing normalization (which is always legal per the proposed spec). Would it be feasible to spec that equivalent URIs simply do identify the same resource, and if different representations are returned for different forms, it's a strange but unambiguously identifiable resource? (That's exactly already the semantics for URIs resolved by servers using their file systems,which is the most popular method. If there's an RSS feed at , then the file gets deleted, and after some time a new webmaster (possibly even not knowing that there used to be an RSS feed) places an icon (like ) there (and configures the appropriate ), the resource doesn't change. It's just a weird resource whose representation (independent of other factors, thus no ) is an RSS feed for some period, then it has no representation ( or ), and still later it's represented by an icon.) It doesn't break backward compatibility with implementations doing crazy things, those things remain technically spec compliant, it just pinpoints the semantics, saying that, despite possibly different representations, some things are the same resource (which current specs leave unclear, so some might have assumed otherwise, but, as I wrote above, it's such a corner case that I'd be surprised to learn that somebody actually not only held this interpretation, but also relied on it). The added burden of compliance to the stricter semantics is on people minting URIs for resources. And if they're unaware of normalization, we'd actually do them a favour by defaulting to the anyway likely desirable thing – having all those other equivalent forms of the URI identify the same resource (and yield the same representation, unless they put enough effort to circumvent normalization and have different representations for the same resource depending on which of the equivalent URIs was used, but doing that indicates they do know of this stuff). One more nit. Is normalization all or nothing? Or are HTTP components allowed to e.g. only omit port 80 and keep dot segments? I think it should be specified and prefer the former (which also follows Postel's law), though I realize there may be popular implementations doing otherwise; if so, a SHOULD is probably the most that could be counted on. (For completeness: are they allowed to denormalize, e.g. introduce case variation in the authority part?)


The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).


without changing section numbering
implies that a precondition failure is a good safe mode. However, a precondition that isn't recognized by a server will not share this property. A server that does not recognize a header as a precondition will ignore it and likely proceed with handling the request even if the precondition expressed should have failed. Indeed, the same is true if a server ignores preconditions, though the specification effectively . is the only text I could find on defining new preconditions. (One thing I really want to avoid is server's applying special heuristics to headers that start with , because that is one of many poor outcomes if this is left.)
There is also the example in the section above that I suppose we could make a new section on precondition extensions, but they aren't a separate category (like If*). For example, my precondition proposal for 1.1 was an all-inclusive Unless that enclosed a logic bag (structured field value). Note that they have always depended on compliance-when-implemented, since I added the first (If-Modified-Since) in early 1994.
Does this need to be in this specification?
I think we're almost in the extension territory (I like the idea of a header field that lists the applicable precondition fields). As far as this specification goes, simply noting that new preconditions won't share properties of the core preconditions, in particular the expectation that it is understood by servers.
One grammatical nit.


to clients that attempt to guess (editorial)
I have no idea what this is trying to say and it is 1.1-specific. I suggest we delete it.
It was added as part of URL, adressing .
How about
May end up encouraging this kind of implementation, by providing an example here ... ? Maybe just leave this as "Some clients take a riskier approach and attempt to guess when an automatic retry is possible because the original request may not have been received by the server." ....
I don't see any problem with the original text, but NAME your replacement is fine too (although the second sentence is a fragment).
How about


I am seeing a lot of warnings about lines being too long (longer than 72 characters), but they are unrelated to these changes.
This changed "previous authors, editors, and Working Group Chairs" to "current and previous authors"; that's misleading, as it actually does not contain any current authors. Originally posted by NAME in URL
This is what I had in mind in terms of bringing back the original acks.


Nits on semantics flags this: -- The draft header indicates that this document updates RFC3864, but the abstract doesn't seem to mention this, which it should.
Can you point to a document that states this?


Should we leave these open until after IESG last call, or just apply them now?
Good Q. NAME ?
I think it'd be preferable to not cut another version until we get through the IETF last call. However, if we want to merge this and just keep a note of the changes, I don't see any issue.
I think it would be preferable, just to avoid people raising the same issues again, and also to get the Index into the last call version.
HEAD says whereas the new text for GET is and similarly for DELETE. We should update HEAD as well to be
Digging in the change logs: the text for GET comes from URL (with subsequent tuning).


Used in 5.6.1, defined in 5.6.3. Minimally make the forward reference explicit.
And 5.3.


Hi! I post here my combined comments for draft-ietf-httpbis-semantics-16, as I don't think they deserve one issue each :) I hope that's fine. My comments range from minor to very minor to nit, and are mostly editorials and clarifications. As this can possibly be me, I'll leave it up to you to decide if they can be useful to improve readability, or not. Thanks for your work! Francesca [x] 1. ----- Additional (social) requirements are placed on implementations, FP: I am not sure I understand the meaning behind the term "social requirement". Editors: URL (URL) [x] 2. ----- When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version. FP: I had a hard time parsing this sentence (starting at "and is used..."), maybe breaking it up with commas would be enough. Especially the two "that" are unclear to me. Editors: URL (URL) [x] 3. ----- RFC 3986, which allows for an empty path to be used in references, FP: very minor, I'd prefer "in URI references". Editors: URL, change applied in URL [x] 4. ----- The process for determining that access is defined by the URI scheme and often uses data within the URI components, such as the authority component when the generic syntax is used. However, authoritative FP: I had to read the sentence above 3 times before realizing that the subject of "is defined" is not "access", but "The process", and understanding it. Editors: URL, change applied in URL [x] 5. ----- A client MAY discard or truncate received field lines that are larger FP: I assume and It might have been good to clarify that "truncate" a field lines is equivalent to dropping a member of the list of values. Editors: URL [x] 6. ----- Note that double-quote delimiters are almost always used with the quoted-string production; using a different syntax inside double- FP: I am not sure I understand "quoted-string production" Editors: added missing fwd reference - URL [x] 7. ----- content, it is often desirable for the sender to supply, or the recipient to determine, an identifier for a resource corresponding to that representation. FP: It might have been good here to give a hint or example on why such identifiers could be desirable. Editors: URL (URL) [x] 8. ----- Fields (Section 5) that are located within a trailer section are are referred to as "trailer fields" (or just "trailers", FP: s/are are/are Editors: URL [x] 9. ----- All responses, regardless of the status code (including interim responses) can be sent at any time after a request is received, even if the request is not yet complete. A response can complete before FP: I think at this point in the text there is no definition of what qualifies a request or response being "complete". Editors: actually, the definition is earlier in the text; added a reference anyway: URL [x] 10. ----- An intermediary MAY combine an ordered subsequence of Via header field list members into a single member if the entries have identical received-protocol values. For example, FP: Is there any requirement on the intermediary to be able to collapse the ordered sequence into a single member (such as storing and being able to expand this information)? Might want to expand a little. Editors: Declined because there is no requirement to do so. We already explain that one might want to do so for information hiding of intermediaries within a private network (URL and URL) [x] 11. ----- This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access FP: I might be missing the motivation for it, but this paragraph seems strange to me. Why is it important that the client cannot be held accountable for it? The concern I have is that the text seems to be saying "safe is essentially read only/not harmful/..., but not really". (And same for idempotent) Editors: URL [x] 12. ----- referring to making a GET request. A successful response reflects the quality of "sameness" identified by the target URI. In turn, FP: I am confused by this terminology: quality of "sameness". Editors: URL [x] FP: The text could add something for when it is acceptable or expected to make sense (so why this is a SHOULD). Editors: Because the protocol has historically preferred to separate semantics from parsing requirements so that the semantics can be extended over time without breaking parsers. It is a SHOULD NOT for GET because the original protocol did not define a meaning for such message content and some implementations took advantage of that leniency to implement and deploy features that work among consenting implementations but are non-interoperable with intermediaries and other implementations. Hence, it's a bad idea, but the protocol does not prevent it from happening. See for why this is impossible to change. [x] 14. ----- A server SHOULD NOT use the From header field for access control or authentication. FP: Same as the previous comment, when is it acceptable to use the From header field for access control or authentication? Editors: URL [If it is acceptable to the server that does it, then HTTP doesn't care in terms of interop, but it is still a bad idea because the protocol has other mechanisms for doing access control and authentication which are less likely to be leaked by accident (URL)] [x] 15. ----- FP: I don't know if I missed it, and please correct me if I did, but I was hoping to find a sentence stating something of the sort for the header fields: "If not otherwise stated, these fields can be used with any method or response code". Editors: URL [x] 16. ----- FP: Most of the header fields contain examples, which I find helpful. I think it would be good to have examples for all of them (including TE, Trailer). Editors: URL [x] 17. ----- | Accept. Future media types are discouraged from registering | any parameter named "q". FP: I wonder if it would be worth making a not out of it in the media type registry (so that it's easily remembered by experts) Editors: URL [x] 18. ----- Note that an If-None-Match header field with a list value containing "\" and other values (including other instances of "\") is unlikely to be interoperable. FP: what does it mean for a header field specific value to be not-interoperable? I am also not sure how "*" between the list of values would be processed. 2. above does not specify it, only stating: If the field value is a list of entity-tags, the condition is false if one of the listed tags matches the entity-tag of the selected representation. FP: I would possibly interpret this as "search for tags matching the entity tag - ignore all others". Editors: URL and URL [x] 19. ----- senders might send erroneously send multiple values, and both FP: remove one "send". Editors: URL [x] 20. ----- the String data type of [RFC8941]), or a field-specific encoding). FP: remove the first parenthesis. Editors: URL [x] 21. ----- FP: This is more of a check, but I see that all references only point to sections. I hope this will be translated into "x.x.x of RFCthis", is that correct? Editors: URL
You mean in the tables for IANA registrations? That's for brevity; IANA knows how to deal with that.
The media type registry is not owned by "us". I don't think we have the authority to change it.
I will look into this with IANA and the DEs and get back. Just to be clear, the document states "future media types are discouraged..." but what we really mean is "experts should be conservative with assigning ..." , is that accurate? Yes, in theory we'd like to discourage media types to be registering "q", but the practical way to make sure that doesn't happen is to make the DEs react to it if it does.
maybe "...whenreferring to that protocol version..."? NAME ?
Yes, thanks!
I don't think it's restricted to that.
For instance, to provide a bookmark/make something accessable for a subsequent GET... NAME - do you want to add that?
I don't get that question. The spec allows collapsing. It doesn't require it. Could you please clarify your question?
The motivation is that if something is defined as "safe", I can URL do that operation without being held accountable. For instance, I can always GET a URI (such as for prefetch/preload/indexing) and if the server does do something stupid with that request (such as deleting a resource, or adding something to a shopping basked), it's their problem. Re idempotenty: this makes it possible to repeat a request.
The text states that intermediaries are allowed to collapse "an ordered subsequence of Via header field list members into a single member", and they can only do so "if the entries have identical received-protocol values." So I read 2 rules: the order matter, i.e. if (A,B) collapses to C, (B,A) does not map to C (A,B) must have identical recived-protocol values I was wondering about any additional rules that the intermediaries have to follow in order to collapse the list into one: for example, is it ever expected for the intermediary to remember that this single member was this collapsed ordered sequence? Are they ever requested to un-collapse?
Order matters for the purpose of collapsing. If you have "D, E, F", and E has a different protcol than D or F, you can't collapse. If "A, B" can be collapsed, so can "B, A" (because they have the same protocol) We are not saying that, so there is no expectation that the collapsing can be undone.
Ok, so yes I understand - the idea of this text is to say: "this is the intent, BUT be aware that implementations might do something stupid and not comply with this intent." I guess what I got stuck with was "the client can't be held accountable", as it wasn't clear to me what would it mean for a client to be held accountable, as clients in general are not aware of what's the action on the server their request will result in.
This might require a separate issue. A field value containing more than one list element and including "*" is invalid, and the spec really doesn't say what that means. The intent of saying "interoperable" is (IMHO) to prevent people from assuming the different servers will do the same thing with it. I believe we should clarify that a value like that is invalid, and thust MUST NOT be sent. NAME , NAME ?
That refers to URL - I guess we should cite that? NAME ? Edit: opened URL
On the other hand, people complain about the spec being too long already. I don't think we should add examples unless they are needed to make things easier to understand.
Ok! (As I said, these are so minor that they are definitely up to you. Same with references and terminology comments)
I believe the simplest possible fix would be to remove "to be used in references", making this: NAME ? Edit: -> URL
I think that we should probably convert this one (and similar) to MUST NOT -- there isn't any situation where we recommend this behaviour, as it has interoperability and security implications.
Not convinced at all. The "SHOULD NOT" requirement is new and was controversial already. There is code out there using GET with body (in controlled environments) which just works.
That's not HTTP; that's a private protocol.
Tell that Google :-) Anyway. This is a normative requierement and we are past WG LC. If you want to change it, this absolutely needs to be confirmed explicitly by the WG (and would deserve a seaparate issue).
Maybe "The process for determining whether access is granted is defined..."? Edit: -> URL
You mean generally, for the fields we define? I don't think that's true; they're defined for the semantics they specify. If a use isn't specified, it might be extended in the future, so we rarely prohibit such a use. Saying that they can be used with any method or status code would imply that they have meaning in each circumstance, and that's often not true.
authentication. This isn't important for interoperability, it's just a bad idea. Maybe 'The From header field is not intended or suitable for use as a means of access control or authentication.'?
FWIW, the requirement is from RFC 7231, and widely accepted (I guess), so I don't think we should change it.
For 4, proposed rewrite:
WRT -- I don't think I'd use the word "widely" in conjunction with this header field. Again, if we use SHOULD NOT, we should explain the qualification.
In the sense that it's an interoperability requirement on a sender (not a recipient), I agree.
"MUST NOT be generated" maybe?
MUST NOT be generated, because recipient behaviour is not interoperable.
URL already say "MUST NOT generate ABNF-invalid messages" in general. So maybe we don't want to repeat BCP14 terms here... -> URL
I've reviewed the most recent commits, think this can be closed now.
Thanks for addressing my comments. I checked the commits and your answers: I can see everything was addressed, either by changes or by answers clarifying what I found confusing, except for: the one which is now issue point 14: giving context around the "SHOULD NOT" for the 'From' header field. Note that I am not asking you to make any change (such as removing the BCP 14 text), but following what BCP 14 defines: it seems important that the reader understands, or at least gets a hint of what these reasons and particular circumstances are, in order to be able to understand the full implications. This is why I think it's important to clarify the context around the SHOULD / SHOULD NOT, and was also my comment for the GET requirement, but I see that that comment has now transformed in a bigger issue the wg needs to find consensus on.
I disagree. You are presuming that we know those particular circumstances, and that is almost always false when SHOULD is being used. When we have a detailed list of conditions, we use "MUST NOT unless ...". The SHOULD is literally saying that the reader needs to take care and understand the risk/benefit for their own context, not that we need to explain to them based on our own imagination. It is fine to suggest additional text to address a specific concern, but I personally think that this one is self-explanatory. If we added a general description about why auth parameters shouldn't be sent in fields that are not expected to be treated as auth parameters by every recipient, such as within a security consideration, then we could reference it here.
I don't think we should know all possible circumstances, but I presume we do have an inkling that implementations going against the RECOMMENDations exist, for whatever reason, right? As a reader, putting myself in a new implementer shoes, I personally would have found it useful to get that hint of what to consider, but if you think that this one is self-explanatory, I won't insist. The type of sentence I was thinking about would be something like: (Just trying to explain myself here, again, feel free not to take this suggestion if you and the wg don't think it helps the reader)
Okay, I have added URL because I think we should explain it if it isn't obvious to others.
Thank you NAME !


It is spelled as Acknowledgments in every RFC. Fix the one inconsistent case instead.
FWIW, I checked the style guide. Will check again. That doesn't support what you say. The current text uses the slightly minority spelling which is also the one used in the RFC Styled Guide. Feel free to flip to the other spelling if you have a strong preference.
Well, FFS, the style guide also says to use either US spelling or British spelling, but not both. It is spelled Acknowledgments in the US and all RFCs prior to that style guide. The RFC editor deliberately changed my text to Acknowledgments the last time this came up. I don't care which way it is spelled.
[x] Section 9.1. , paragraph 2, comment: I'm not sure I understand what is meant by "transport link" and how connections would "apply" to one. Editors: URL
[x] Section 9.4. , paragraph 4, comment: Using larger number of multiple connections can even cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. Editors: URL
[x] Section 13.1. , paragraph 14, comment: This can become an informative reference, so to not create a DOWNREF, since it's only used in the description of an IANA codepoint. Editors: URL
[X] Section 13.2. , paragraph 12, comment: I think it is common practice to normatively cite an RFC that is being obsoleted. Editors: URL
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
[X] Section 9.3. , paragraph 3, nit: This got garbled, the suggestion was to rephrase to: A recipient determines whether a connection is persistent or not based on the protocol version and Connection header field in the most recently received message (Section 7.6.1 of [Semantics]), if any: Editors: URL
[X] Section 11.2. , paragraph 2, nit:[X] Section 12.3. , paragraph 3, nit: Editors: this is intentional. Leave it to the RFC Editor?
[X] Section 7.1.1. , paragraph 6, nit: Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". Editors: URL
[x] Section 9.5. , paragraph 2, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Editors: URL
[x] Section 9.8. , paragraph 2, nit: The abbreviation is missing a period after the last letter. Editors: URL
[X] Section 10.2. , paragraph 17, nit: Consider using "many". Editors: this is in 11.4. URL
[x] "Appendix B. ", paragraph 2, nit: Did you mean "ought to stop"? Editors: URL
[x] "B.3. ", paragraph 2, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. [x] "B.4. ", paragraph 1, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Editors: URL
[x] "C.2.2. ", paragraph 4, nit: This abbreviation for "identification" is spelled all-uppercase. Editors: URL
[x] Uncited references: [RFC7231]. Editors: URL
[x] Obsolete reference to RFC2068, obsoleted by RFC2616 (this may be on purpose). Editors: this is indeed intended, as we're citing something that is in 2068 but not 2616
[x] These URLs point to URL, which is being deprecated: URL URL Editors: these are added by xml2rfc; you may want to open a ticket for that tool :-)
[x] These URLs in the document can probably be converted to HTTPS: URL Editors: URL
It is used normatively for the definition of the "compress" coding. (also, this is no change from RFC 723x).
Sorry? We are obsoleting that spec, thus we will not have a normative dependency on it.
would "apply" to one. Suggest:
otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. With some light editing, I think this would be useful to add.
I think we should commit this now and let the RFC editor decide on spelling.