jiebi/CodeConvo huggingface dataset:
Code change:
Error code: "entryNotFound" <del> 2.1.4. </del> <ins> 2.2.4. </ins> <del> 2.1.4.1. </del> <ins> 2.2.4.1. </ins> <del> 2.1.4.2. </del> <ins> 2.2.4.2. </ins> One of the following:

Related discussion:
text: The transparency service knows that animal products require certificates to be imported, and issues a challenge token that looks like this: iss: "https://transparency.example" aud: "https://transparency.example" iat: ${now} exp: ${now + 7 day} currenttreehead: ... (not all TS are trees) currentpolicyhash: ... (not all policies are stored in trees) entrynumber: 42 htscodes: [ 16056100 ] The holder starts registering signed statements, each is bound to the same "challenge token". The first signed statement covers a phytosanitary certificate for the sea cucumber processing facility. The regulatory requirements change. The second signed statement covers the (now required) export certificate for sea cucumbers. The transparency service would normally have rejected the second signed statement, but because of the context in the challenge token, the transparency service knows that the second signed statement is now actually required. The holder did not need to request a "new challenge token" when the regulatory changes happened, and the holder still had to prove possession of the public key bound to both certificates ( and these public keys are different ). I chose to make this context scenario about sea cucumbers, but it could easily have been about network capable hardware devices that need to comply with regulations specific to Radio Antennas and GPUs... In those cases there would be firmware certifications required, and compliance requirements might change inside the transaction window. This also solves the problem of forcing the issuer to commit to the registration policies as they exist at the time the "challenge token" is issued. The TS can reject registrations that are committing to stale policies, or accept registrations that are commiting to stale policies, because the TS will know which policies the issuer is committing to by checking the challenge token. In the case that proof of possession is not required, and there is no need to commit to policies, the challenge token can be omitted, and the registration can proceed exactly as it is specified today. OS ORIE STEELE Chief Technology Officer www.transmute.industries
Code change:
While input_string is not empty: If the first character of input_string is not one of lcalpha, <del> DIGIT, "*", "_", or "-", return output_string. </del> <ins> DIGIT, "_", "-", ".", or "*", return output_string. </ins> Let char be the result of removing the first character of input_string.

Related discussion:
text: Allow "." in . Also consistently reorders character lists for key.
I'm getting a high failure rate on parsing (but with a very low number of occurrences; it's not exactly a popular header). The failure seems to occur because of keys like this: Allowing in key would address this, but I'm not sure it's worth the change. Additionally, key currently only allows lowercase alpha; this is mainly to avoid confusion between and , etc. So far this seems to be pretty supportable in cache-control, accept- and elsewhere, with the vast majority of headers seeming to choose the lowercase form. However, it does cause issues in a couple of cases: In , the parameter isn't compatible, leading to a high failure rate for that header In cookies, this makes a number of things incompatible, but it's not clear that we can treat them as a direct mapping anyway.
I have no opinion about dots. As to case, though; I think the options are: say lower-case only – the current option we should probably instruct individual headers' specifications to define how to get into/out of SH, which is harder for extant specs open it up to anycase and be case-sensitive this means that parses to and if someone wants to collapse / they have to do it after the fact open it up to anycase and be case-insensitive still requires instructions for individual headers' specs to define how to get out of SH Incidentally we don't say anything about case for tokens, not that it matters as far as SH is concerned (we never have to compare them.) It might not hurt to say something to the effect that "tokens are case-sensitive so you aren't allowed to change them, but an individual specification that uses sh-token may have special rules for comparing tokens that only differ in case".
WRT lower-case -- I think your analysis is correct; my inclination is to either stay lc only, or to force to LC when parsing textual headers (much like H2 does for field names). WRT instructions for existing headers -- that's out of scope for SH "officially."
Your patch for looks good. Force-lowercasing makes me a bit nervous, because the wire form for h1 will be materially different than what appears in the data model. We'll have to be careful to distinguish between the h1 wire format and the abstract model for keys (which we currently are pretty sloppy about).
Code change:
While input_string is not empty: If the first character of input_string is not one of lcalpha, <del> DIGIT, "*", "_", or "-", return output_string. </del> <ins> DIGIT, "_", "-", ".", or "*", return output_string. </ins> Let char be the result of removing the first character of input_string.

Related discussion:
text: More seriously, even if we did force-lc, I realise it wouldn't be possible to round-trip things like includeSubDomains, so it probably isn't going to be useful on its own; there will always need to be some application knowledge / mapping. So, I'm inclined to leave casing in keys as-is.
I don't know what you mean by "force-lowercasing". Is that different from leaving it as-is?
i.e., forcing LC when parsing textual headers, as per above.
Oh, do you mean converting "FooBar" to "foobar" as part of some algorithm? Right, yeah, no, I don't like the idea of coercing data into the model if it can't be round-tripped back out. If an individual header field's spec supports a different data model (e.g. strings), then it's up to that header field's spec to define how to convert their string to an sh-key, and back again. I.e. don't do anything in SH, and punt it to RFC6797bis (or draft-mnot-bsh).
Agreed. Could you make the change into a PR?
It is.
Code change:
report to the specified "report-uri" as specified in reporting- expect-ct-failure. <del> If a UA receives more than one Expect-CT header field in an HTTP response message over secure transport, then the UA MUST process only the first Expect-CT header field. </del> The UA MUST ignore any Expect-CT header field not conforming to the grammar specified in response-header-field-syntax.

Related discussion:
text: This changes Expect-CT to be a comma-separated list of directives (which may be name=value pairs), and adds some examples. Also allows the server to send multiple header fields so that they can be combined, as per URL Fixes issue ,
Would it be possible to include an example in the spec? Something like... Expect-CT: enforce; max-age=3600; report-uri="URL" As I believe most developers like to work with examples, rather than just using the spec definition as found under the heading "Response Header Field Syntax". :-)
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return dictionary (which is empty). </ins> 4.2.3.

Related discussion:
text: This modifies parsing to consider empty or not-present header fields as empty containers; serialisation omits them from output.
The SH syntax does not directly allow empty field values, such as defined for Accept, although this might be allowed by field definitions like MyField = [ sh-list ] Likewise, the list types do not allow for empty lists. sh-list = list-member *( OWS "," OWS list-member ) list-member = sh-item I think this is a very odd choice for a generic syntax because the empty set is often given semantic meaning in generic communication. It's hard to do math without zero. If this is intended, the rationale should be explained in the spec, and there should be some discussion with examples about defining fields as an optional value.
FWIW, even if empty lists may be problematic top-level, the situation is different when they are nested...
ietf104 - interest in the room in supporting empty (perhaps null?) syntax
I agree this is something important. It may be used to mean "I know I must pass the info but I don't know the info", which is different from "I don't care about the protocol" or passing a dummy value just to fill the hole.
In the original base material of header definitions, empty values were generally just not sent at all. Having a specific Null value may or not make sense, not sure.
I personally like the distinction between "known to be empty" and "not presented either because I don't know or because it's empty". Some semantics might explicitly require the presence of some fields which we would enforce by the protocol. This doesn't mean they can't be empty, they must be present, for example, to make sure they weren't dropped in the middle. For example, "Connection: foo" gets rid of the field, not just the value. Just my two cents, Willy
Do we have any RFC'ed headers where there is a difference between a non-present and an empty header ?
There's an accept-something if I remember well. Also I've been using "Host:" in many occasions with HTTP/1.1 requests when I didn't know the host name and this tends to work where no Host field fails ;-) Willy
I'm not against a '?N' null token (along the lines of true/false), but I have a hard time thinking of a use for it.
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return dictionary (which is empty). </ins> 4.2.3.

Related discussion:
text: URL
Wouldn't an empty list be equivalent to an empty value, thus we don't need a new syntax?
Putting an empty list where for instance an integer is expected, just to say that there will be none, sounds counter-intuitive to me.
On Fri, Apr 05, 2019 at 01:37:11AM -0700, Julian Reschke wrote: Indeed, probably.
On Fri, Apr 05, 2019 at 03:11:00AM -0700, Poul-Henning Kamp wrote: Agreed in general. My point was that sometimes specs use "MUST send" when the sender doesn't know, resulting in stupid values appearing. That's exactly what led a number of agents to place a content-length with stupid values (0 or huge ones) with the CONNECT method a long time ago. An empty value where an integer is needed by the application is more of an application-level error than a protocol-level one in my opinion : it's up to the application to decide how to recover from this missing piece of information (is it really needed to process the request or not). For me it can mean "don't care", "don't know" or "not representable". After all floats support "NaN" for the same reason :-) Willy
If there is a "MUST send" requirement, there must also be something available in the same spec that can be sent ?
There is not, and never has been, an interop problem with sending empty field values. They are a list value of zero items or a string item of zero length. Accept and Host, respectively.
NAME how do you know that?
Because if a recipient drops an empty Host field the request will be rejected with 400. There have been no reports of such breakage in 25 years. It isn’t even a likely scenario given how message fields are parsed and reproduced.
If a recipient doesn't drop an empty host header, the request will still be rejected with 400, surely? Regardless, I'd note that many headers address this situation with a reserved value like . Is there value in standardising on one such value for future headers?
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return dictionary (which is empty). </ins> 4.2.3.

Related discussion:
text: I'm not convinced, but I'd note that we also have many headers that use to denote "all"; it seems to me that if we're going to do null, we should do that too (but again, I'm not convinced this is adding value).
On Mon, Apr 08, 2019 at 05:16:41PM -0700, Mark Nottingham wrote: It depends on the header field that was empty ;-) I've used the empty Host header field quite a bit (even in health check requests). My observation has been that while HTTP/1.1 without Host naturally causes a 400, HTTP/1.1 with empty Host is often processed similar to HTTP/1.0 without Host or as 1.1 with an unknown Host. I'd say "why not", but it's useful to consider lists and the iterative processing that can happen, removing one item at a time. Having to place a specific value to denote emptiness would require specific processing (i.e. check for emptiness after removing any item just for the sake of replacing it with the special value). By the way, speaking about lists makes me think we may complicate interop when a header field appears multiple times. For example if we have this in a request : List: a,b,c,d Foo: bar List: e,f,g,h It's not unreasonable to think that some simplified implementations may replace the first occurrence of List with "none" after processing it, leading to this : List: none Foo: bar List: e,f,g,h Or possibly this : List: none Foo: bar List: none Which may be processed as "List: none,e,f,g,h" or "List: none,none" respectively. Just my two cents, Willy
Willy, I think that would be clearly broken, and we should be able to catch it with tests. I think we're talking about all of the container types here (dict, list, list of lists, parameterised lists), correct? Julian, you gave as an example. Given that the behaviour recommended is exactly the same as if the header was missing, that's not very compelling. Besides the potential stripping issue (I have heard of implementations that strip empty headers, but don't have details on hand), some header libraries may not make a distinction between missing and empty headers.
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return dictionary (which is empty). </ins> 4.2.3.

Related discussion:
text: Overall, I don't see a lot of value in accommodating empty headers directly, and I don't think we should be promoting it as a practice.
Agree, I'm not convinced either. I see the potential, but Gettys rule applies: "The only thing worse than generalizing from one example is generalizing from no examples at all." (May actually be from Phil Karlton originally, sources differ.)
Hm, no. "A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings." vs. "An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response."
Yes, but in the real world, the outcome is always the same.
No. HTTP/1.1 introduced an IESG requirement that Host must always be sent and recipients must always reject with 400 if Host is not received. When I pointed out that not all URIs have a host, the response was that clients must send an empty Host field in that situation. It is a MUST requirement in Semantics section 5.4: This is ingrained in HTTP semantics and commonly used by non-browser HTTP implementations. There is only one example of an HTTP header field using "none" and that is Accept-Ranges. It isn't a good example for anything. To be clear, it would be a bug for an HTTP message processor to drop a received header field just because the value is empty. Nothing about SH will change that. What we are discussing is whether SH is capable of representing an empty list or an empty header field, both of which it is currently incapable of doing.
If that spec specifically says "empty field-value", a SH "empty" token will not be usable for Host: anyway, and we're back in the "generalizing from no example at all" again.
On Thu, Apr 11, 2019 at 03:53:15PM +0000, Poul-Henning Kamp wrote: After having thought a bit more about this, I now think that we don't need empty list elements in the end because lists are not strongly ordered, they're not arrays with a position so an empty element in a list brings no value.
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return dictionary (which is empty). </ins> 4.2.3.

Related discussion:
text: I'd further say that removing an element from a list must result in removing the list once the last one was removed as it is a set. So I think I'm fine with not dealing with empty lists. This then leaves us only with the empty header field alone, likely where a string or a token are expected. I don't see a reason not to support an empty string just like any other string. A header field is not just a value, it's a name+value combination. With a void value the name still serves as a boolean (present or not) and this is exactly how it's used when the field is made mandatory to distinguish between agents generations or as a signal to detect support for something. We've all filled administrative forms where the requested information was irrelevant but mandatory in the form and just left it void so that the person in charge deals with the particular case (on paper) or filled with whatever was accepted (on web forms) hoping it would just be ignored since irrelevant. For me the Accept and Host fields are exactly in this category. My concern is to be certain that a valid HTTP request can be transmitted over SH. And ironically, the only mandatory HTTP header ("Host") is also the one requiring the support for an empty value due to its mandatory nature. Willy
I have lost count of the number of packages I have received from USA where part of the address is "Denmark does not have states" :-)
Again, the purpose of SH is not to allow all possible HTTP header to be represented in the data model -- it's to solidify the 80% case and promote best (and interoperable) practice. Representing a boolean as an empty header field is not good practice.
See PR above.
I've put in the changes for the list-based header fields. It's less clear to me that it's desirable to default a missing or empty item to an empty string (strings and tokens) 0 (integers and floats), False (boolean) or a 0-length binary array (binary data); to me, those are all going to be application-specific defaults that are better specified explicitly. I'm happy to adjust the spec to make that more clear, if folks feel it already isn't.
Code change:
A recipient SHOULD treat other octets in field content (obs-text) as opaque data. <del> Field values containing control ( ) characters such as CR or LF are invalid; recipients MUST either reject a field value containing control characters, or convert them to SP before processing or forwarding the message. </del> <ins> Field values containing CR or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message.  Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake of robustness if they only appear within safe field value contexts (e.g., data not required by HTTP). </ins> Leading and trailing whitespace in raw field values is removed upon field parsing (e.g., field.parsing).  Field definitions where leading

Related discussion:
text: 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.
Code change:
all times, when a new host arrives on the AIL, it is able to acquire an IPv6 address on that link. <ins> During all of the states mentioned here except for state-unknown, the SNAC router is expected to treat the infrastructure interface as an Advertising Interface as described in RFC4861.  There are two sets of information that need to be sent in an RA; if neither is present, then the SNAC router SHOULD NOT send an RA even if it is treating the infrastructure interface as an advertising interface. These two sets of information are the on-link prefix, if any, that is to be advertised.  Whether or not such a prefix is advertised, and what exactly is advertised regarding that prefix, is determined by the state machine.  The other set of information is a set of routes to prefixes on the SNAC network.  Whenever we know of a reachable (scope is not link-local) prefix on the SNAC network, we include an RIO option in the RA on the infrastructure network indicating that that prefix is reachable through the SNAC router. It is important to note that it is possible for an on-link, routable prefix to be advertised and then withdrawn on the SNAC network, but for it to still be valid, and for there to still be some communication occurring using that prefix.  In order to avoid prematurely interrupting such communication, the SNAC router MUST maintain a list of prefixes known to be valid on the SNAC network, even if those prefixes have been deprecated, and MUST include RIO options for all such prefixes in the RAs that it sends on the adjacent infrastructure link. </ins> 5.1.2.1. When the stub router interface first connects to the AIL, it MUST

Related discussion:
text: Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.
Code change:
1.4. This specification uses the terms "Holder", "Issuer", "Verifier", <del> "Key Binding JWT" defined by I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> "Key Binding", and "Key Binding JWT" defined by I-D.ietf-oauth- selective-disclosure-jwt. </ins> 2.

Related discussion:
text: also fix a typo or two for Issue
URL has "Combined Format for Presentation", which isn't used in SD-JWT anymore.
I assigned you NAME since you are one of the SD-JWT editor's.
Gotta start somewhere... hopefully I can handle this one. PR has proposed changes.