jiebi/CodeConvo huggingface dataset:
Code change:
For example, the Date HTTP header field carries a date: <del> Its value is more efficiently represented as an Integer number of delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970, minus leap seconds).  Thus, the example above would be mapped to: </del> <ins> Its value would be mapped to: </ins> As in compatible, these fields are unable to carry values that are not valid Structured Fields, and so an application using this

Related discussion:
text: I still believe this change should end up in the revision of SF.
That's
Some have pushed back on using integers for dates, see eg URL As I suggested there, one accommodation would be to define a new structured type for them. That could be done in retrofit, or separately.
I see no mention of fractional seconds ? I think we need to ponder that, if the goal is (eventual) convergence for all timestamps in HTTP ? Considering how much effort we spend on speeding up HTTP, I find the "human readable" argument utterly bogus. Only a very tiny fraction of these timestamps are ever read by humans, and most are in a context where software trivially can render the number in 8601 format if so desired. In terms of efficiency, I will concede that, in a HTTP context, it is almost always possible to perform the necessary calculations and comparisons on raw ISO-8601 timestamps, without resorting to the full calendrical conversions, but once all the necessary paranoia is included, I doubt it is an optimization. My preference is seconds since epoch, (and this is largely why has three decimals in the first place), because it gives us fast processing, good compression and millisecond resolution. PS: A Twitter poll with only 40 respondents, carried out on the first monday after new-years ? Really ?!
One argument against any "seconds since epoch" representation is that (at least under the ) it is incapable of representing an instant within a positive leap second (since "each and every day shall be accounted for by exactly 86400 seconds_", any such time would be interpreted as being in the first second of the following UTC day).
For HTTP I think subsecond precision is an overkill due to RTT / intermediaries.
IMHO: I like structured format. There are a lot of diagnostics and other software that would not want to do additional transcoding of header elements but just represent them verbatim as they occur. Those are helped if the verbatim representation is already easier readable. I do not think TZ belongs into a time/date representation. Aka: all date/times in UTC please. TZ can be added somehow as a "location" information, ideally in a different header field. If it is in the same header field, it would be confusing to show the time in UTC but ALSO to indicate the TZ.
Code change:
For example, the Date HTTP header field carries a date: <del> Its value is more efficiently represented as an Integer number of delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970, minus leap seconds).  Thus, the example above would be mapped to: </del> <ins> Its value would be mapped to: </ins> As in compatible, these fields are unable to carry values that are not valid Structured Fields, and so an application using this

Related discussion:
text: Maybe this can be resolved by coming up that would make it as obvious as possible that the date/time is NOT adjusted for the TZ shown. Maybe not call it "TZ" but "LOC" so that the "the date/time it TZ adjusted" recognition is not triggered. And of course waste the three characters on "UTC" in the representation. I do not believe the processing speed argument to be valid. The level of processing speed where just a (sub)second unstructured value would help goes IMHO into the space of CoAP, not HTTP. I'd first try to make HTTP better where it does not just duplicate CoAP efforts. All that binary stuff CoAP needs to do is severely making toolchains more complex IMHO. I do like the leap-second argument. I do think msec accuracy should be an option. RTTs within lan/metro environments can easily be in the single digit msec range and you want to be able to diagnose e.g.: REST based broker/bus-type transaction speeds, relative ordering of request/replies.
Seems reasonable to me. +1 Not sure this is an "interface" that HTTP exposes / should be relied upon.
I suspect the experience of pretty much everybody writing and deploying HTTP intermediaries and servers at scale is different -- at those rates, cycles wasted on parsing do matter, especially when architectures have many layers of intermediaries to go through.
See linked PR for a proposal.
Re leapseconds: as written ("excluding leap-seconds") means that timestamps will be illegal, effectively mandating POSIX leap-second (non-)handling. To make able to handle leap-seconds requires that every HTTP handling entity needs an up to date file, either at system level or application level, and that the upper limit on the "internal data model range" becomes indeterminable, since we cannot predict how many leap seconds will happen in the future, nor what sign they may have. That is a total no-go from a systems engineering and complexity point of view, in particular as the rest of the world converges on either papering over leap-seconds or abolishing them. If the textual format cannot handle leap-seconds (without requiring a boat-load of complexity), then, why take the extra expense in CPU-load and code complexity ? As stated earlier, we should go for the more efficient and less error-prone solution: POSIX time_t (with optional milliseconds) as a .
Code change:
For example, the Date HTTP header field carries a date: <del> Its value is more efficiently represented as an Integer number of delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970, minus leap seconds).  Thus, the example above would be mapped to: </del> <ins> Its value would be mapped to: </ins> As in compatible, these fields are unable to carry values that are not valid Structured Fields, and so an application using this

Related discussion:
text: (If we want to designate the timestamps with a senteniel, 'NAME is a particular bad choice, since the HPACK huffmann assigns it 13 bits.) PS: In context of four digit years: Century scale predictions, based on orbital considerations, expect the current leap-second regieme to break down in approx 2000 years, because we will need leap seconds more often than every month.
Do any current HTTP implementations take leap seconds into account? Regarding HPACK - it's one character. Let's not over-optimise here.
I don't know, but leap seconds are explicitly supported by : And the difference between 23:59:60 and following-day 00:00:00 would certainly be relevant for e.g. Last-Modified.
I have spent a lot of time over the years searching, but I have yet to see a 23:59:60 timestamp in the wild...
Now there's a picture in my mind of PHK walking the wilds, searching for an elusive date stamp.
I don't know what counts as "in the wild", but there is certainly documentation of and .
Discussion at IETF114 wasn't conclusive, but we now seem to be focusing on these options: Do nothing. Dates in SF are Integers (unless folks fall back to Strings), and recipients need to know that they're dates and how to handle them. Create a Date SF type along the lines of the PR. The textual representation is human-friendly, and it's identified as a date in a machine-readable way without special knowledge. Create a Date SF type but use an Integer; e.g., . The textual representation is not human-friendly, but it is identified as a date in a machine-readable way without special knowledge. I'll observe that if we believe that we'll eventually have a binary representation of structured fields widely in use, (2) is preferable in that it has the best properties -- it's both efficient and human-friendly. Of course, that's not at all certain. I'll also observe that in the discussions I've had, the people who want human-friendly representation are generally those who are working with tools and developers, "closer" to the application. The infrastructure folks and "lower layer" folks tend to minimise this aspect.
PR updated to reflect (3) above.
I personally support (2) or because it covers similar use cases than HTTP-date.
Code change:
For example, the Date HTTP header field carries a date: <del> Its value is more efficiently represented as an Integer number of delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970, minus leap seconds).  Thus, the example above would be mapped to: </del> <ins> Its value would be mapped to: </ins> As in compatible, these fields are unable to carry values that are not valid Structured Fields, and so an application using this

Related discussion:
text: In case of (3) I think we can just use an Integer SF, like we do Signatures and other specs. Side note: we sometimes hear that RFC3339 is ambiguous. I think it is, and after ~20 years it probably requires a RFC3339bis that clearly specifies a basic profile ( T, Z uppercase; Always ). I'd be happy to start this work.
Why do the number of decimals need to be specified? Surely we could just say the format is nnnnn[.ddddddd] or similar where an integer-only parser stops at whitespace or a '.' while those who care about sub-second parsing continue on until they are satisfied with the resolution or they run out of digits. The senders decides how many decimals to provide, perhaps with a recommendation of three or upto their clock resolution? So "123456789" and "123456789.1" and "123456789.123456789" are all equally valid.
I like this direction; thanks.
Code change:
is unsatisfiable. <ins> If the selected representation has zero length, the only satisfiable form of is a with a non-zero . </ins> In the byte-range syntax, ,

Related discussion:
text: In 416 status code section, remove duplicate definition of what makes a range satisfiable and refer instead to each range unit's definition. In sections on bytes ranges and Range, clarify that a selected representation of zero length can only be satisfiable as a suffix range and that a server can still ignore Range for that case.
Regarding byte ranges, an empty (zero-length) representation is unsatisfiable according to section 2.1, but not unsatisfiable according to section 4.4 if the first-byte-pos is zero. I would like to see an update to the RFC which explicitly resolve this self-contradiction in whatever way seems appropriate. The following is one suggestion, but there may be others: I would like to suggest explicitly specifying that an empty 200 response should be returned in this case. It is the simplest solution to the current self-contradiction in the RFC, since it is a valid response anyway (if the server chooses to ignore the Range header), clients already handle it properly, it provides all necessary information about the representation to the client, and stating it explicitly can prevent subtle edge-case pitfalls in both the RFC and its implementations (as opposed to more intricate solutions). Perhaps the following can be added at the end of section 3.1: "If all of the preconditions are true and the target representation length is zero, the server SHOULD send a 200 (OK) response." (someone in the discussion preferred this to be a MUST, but the SHOULD might be more in line with the previous sections and backward-compatibility if some implementations resolved this in some other way.) I raised this in the mailing list a while back, and it got some discussion and support but did not get officially resolved. More recently I reported it as errata but it was rejected as not being an erratum and redirected here (I apologize - didn't realize issues moved to github, and still not sure what the distinction is :-) ), so here it is, raised again. All suggestions and feedback are welcome.
So how do we get this fixed? There was a discussion about it in the IETF mailing list, in which others confirmed the issue. I opened an errata, but it was closed saying it's not an errata. I was pointed here to open the issue, but got no response in 9 months so far. What can I do to get a response or to help move this forward?
Code change:
is unsatisfiable. <ins> If the selected representation has zero length, the only satisfiable form of is a with a non-zero . </ins> In the byte-range syntax, ,

Related discussion:
text: If the powers that be don't agree that the issue requires fixing, it would be nice to get such feedback explicitly and discuss it. If this issue tracker is inactive and the issue should be posted somewhere else, I'd be happy to do it, just point me in the right direction.
We're not currently working on a revision to this document, so an official answer won't be forthcoming for a while. In the meantime, the best thing to do is to discuss it on list, taking the advice you get there. See Roy's response in particular: URL
Just looked this up to see if it's been forgotten... can I assume from the new labels that it's on someone's todo list and will be looked at eventually, even if it'll take a while longer? (btw the link your referenced actually contains another bug, so I'm referring to both, i.e. the whole discussion).
NAME Thanks for resolving the issues! Better late than never :-) Indeed now there is no longer a self-contradition in the spec, but I'm curious, why did you change your mind since the discussion in the link above, where you seemed to prefer a 200 result for an empty resource (even suggesting a MUST), to the current fix which leans towards the 416 by defining it explicitly as unsatisfiable (with the option 200 downgraded to MAY), or at best makes it a tossup which option servers will implement? Did you have any specific pros/cons or use cases in mind? I guess I still prefer a 200 as the simpler and more straightforward solution :-)
An implementation can choose to send 200. Making that a SHOULD or MUST would be a new normative requirement that isn't justifiable for interop.
ok. Thanks again!
Code change:
this to priority-congestion. The producer may assign a numeric delivery order to each object <del> (delivery-order) </del> <ins> (send-order) </ins> This is a strict prioritization scheme, such that any available bandwidth is allocated to streams in ascending priority order.  The <del> sender SHOULD prioritize streams based on the delivery order.  If two streams have the same delivery order, they SHOULD receive equal bandwidth (round-robin). </del> <ins> sender SHOULD prioritize streams based on the send order.  If two streams have the same send order, they SHOULD receive equal bandwidth (round-robin). </ins> QUIC supports stream prioritization but does not standardize any mechanisms; see Section 2.3 in QUIC.  In order to support

Related discussion:
text: Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.
Code change:
either accepting or rejecting a message based on an unrelated or irrelevant signature.  In order to help an application select which signatures apply to its own processing, the application can declare a <del> specific value for the "context" signature parameter as defined in </del> <ins> specific value for the "tag" signature parameter as defined in </ins> signature-params.  For example, a signature targeting an application <del> gateway could require "context="app-gateway"" as part of the signature parameters for that application. The use of the "context" parameter does not prevent an attacker from also using the same value as a target application, since the parameter's value is public and otherwise unrestricted.  As a consequence, a verifier should only use value of the "context" parameter to limit which signatures to check.  Each signature still needs to be examined by the verifier to ensure that sufficient coverage is provided, as discussed in security-coverage. </del> <ins> gateway could require "tag="app-gateway"" as part of the signature parameters for that application. The use of the "tag" parameter does not prevent an attacker from also using the same value as a target application, since the parameter's value is public and otherwise unrestricted.  As a consequence, a verifier should only use value of the "tag" parameter to limit which signatures to check.  Each signature still needs to be examined by the verifier to ensure that sufficient coverage is provided, as discussed in security-coverage. </ins> 7.2.8.

Related discussion:
text: Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.
Code change:
The SNAC router may receive a Router Advertisement message containing one or more suitable on-link prefixes on the AIL.  If any of these prefixes are different than the prefix the SNAC router is advertising <del> as the on-link suitable prefix, and the 'Stub Router' flag bit is not </del> <ins> as the on-link suitable prefix, and the 'SNAC Router' flag bit is not </ins> set in in the Router Advertisement flags field, the SNAC router moves the interface to STATE-DEPRECATING (state-deprecating). <del> If the 'Stub Router' flag bit is set in the RA header flags field, </del> <ins> If the 'SNAC Router' flag bit is set in the RA header flags field, </ins> then one of the following must be true in order for that prefix to be considered suitable:

Related discussion:
text: Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)
Code change:
"aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this <del> type of Referenced Token.  See section batch-fetching for further detail. </del> <ins> type of Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the CBOR representation of the Status List in Hex:

Related discussion:
text: yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change
Code change:
"aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this <del> type of Referenced Token.  See section batch-fetching for further detail. </del> <ins> type of Referenced Token.  See section aggregation for further detail. </ins> The following example illustrates the CBOR representation of the Status List in Hex:

Related discussion:
text: Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.
Code change:
Algorithms that rely on specific functions or configurations in the network need to provide a reference or specification for these <del> functions (an RFC or another stable specification).  The IETF will need to assess whether the relevant working group is able to review the proposed new algorithm and whether there is sufficient experience to understand any dependent functions. </del> <ins> functions (an RFC or another stable specification).  For publication to proceed, the IETF will need to assess whether a working group exists that can properly assess the network-layer aspects and their interaction with the congestion control. </ins> In evaluating a new proposal for use in a controlled environment, the IETF needs to understand the usage, e.g., how the usage is scoped to

Related discussion:
text: A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!
Code change:
Name: connection_terminated Description: The intermediary's connection to the next hop was <del> closed before any part of the response was received.  If some part was received, see http_response_incomplete. </del> <ins> closed before complete response was received. </ins> Extra Parameters: None. Recommended HTTP status code: 502 <ins> Notes: Responses with this error type might not have been generated by the intermediary. </ins> 2.4.9. Name: connection_timeout

Related discussion:
text: Signed-off-by: Piotr Sikora
So, what's the difference to , then? Should we just remove perhaps?
can be also sent if the connection is terminated before or when sending HTTP request. is more generic and can be sent in response to other events as well (e.g. read/write timeouts). But more importantly, either can be sent in response to the same event (i.e. connection terminated when receiving HTTP response), depending on the existing proxy implementation or various policies, i.e. "proxy should be as specific as it wants to be" from your last email.
Code change:
Cross-device flows enable a user to initiate an authorization flow on one device (the Initiating Device) and then use a second, personally <del> trusted, device (Authorization Device) to authorize access to a resource (e.g., access to a service). </del> <ins> trusted, device (Authorization Device) to authorize the Initiating Device to access a resource (e.g., access to a service).  The Device Authorization Grant (RFC8628) and Client Initiated Backchannel Authentication CIBA are two examples of popular cross-device flows. </ins> These flows are increasingly popular and typically involve using a mobile phone to scan a QR code or enter a user code displayed on an

Related discussion:
text: Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!