jiebi/CodeConvo huggingface dataset:
Code change:
defined in DIGEST to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. <ins> The expected structured field types (STRUCTURED-FIELDS) of any required or expected covered component fields or parameters. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter of the signature parameters (signature-params) and define rules

Related discussion:
text: cc NAME
I would prefer to see your proposal :-). The RFC diff since the last WG version has 143 change blocks: URL We also currently have 17 open issues/PRs: URL IMHO we need to get these closed (can be rejecting or fixing), and also have a look at those that we raised since -13 and closed in the meantime. I don't think we do the community a service by sending this to IETF LC right now.
NAME you are grossly misrepresenting the state of the document. For one, the last WG version, and the one that went to the AD, is -15, not 13, so your diff above is misleading at best. The changes since then have largely not been substantive in nature, and all have been made publicly with the view and input of the WG. The open issues are nearly all addressed by open PRs, which I am waiting for AD feedback before merging (I'm not sure if the AD wants to review the PR text or the merged draft that results). What remains is this issue, as NAME pointed out above. To answer NAME 's question about how to resolve this: I think pointing out as a potential tripping hazard is not necessary but would not be harmful. The precondition to know the type is already in the text as the first sentence about the flag in section 2.1.1: Additionally, the lack of knowledge of the type of the field is already called out explicitly as a required error condition in section 2.5: I would propose we simply add a note to 2.1.1 of the form:
Well, it's hard to say what remains to be done until an issue is actually closed. We're all volunteers here, so it's good to make things as easy as possible to reviewers. So, trying to rephrase: let's get all open issues closed (one way or the other), and let the people who raised the issues give an opportunity to provide feedback before sending this back to the IESG. (I, for once, am not convinced that I agree with the proposed solutions, but due to the type of diffs (long lines) it's a bit tricky to understand what actually changed) works for the sending side; but what is a recipient supposed to do when the sf flag is present and the field value does not parse due to sender and receiver disagreeing about the SF version?
Code change:
defined in DIGEST to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. <ins> The expected structured field types (STRUCTURED-FIELDS) of any required or expected covered component fields or parameters. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter of the signature parameters (signature-params) and define rules

Related discussion:
text: Also, that only affects the toplevel type of the structured field. It does not address the case where an extension parameter is added is an sf-date (or any future new type).
NAME until you propose text, it will be hard to say what kind of text you think would close this issue.
Except for this issue and two others recently raised by you (which will be considered as IETF LC issues), all of the issues and PRs you mention were generated by the AD review before IETF LC; this is a normal part of the process that does not require going back to WGLC unless the AD asks for WG review, which . NAME made a reasonable proposal. If you disagree with it, make your own.
If the proposal was: Then this isn't sufficient as it only applies to the toplevel type (see URL). NAME - I believe you are in the best position to make a proposal; but that said; I can try something later today.
So, we have in 2.1.1: This implies that the "sf" parameter can only be used on fields that conform to RFC 8941, no extensions allowed. I would suggest clarifying that, at the end of 2.1.1, with: "Note that the normative requirement to use the SF serialization algorithm precludes any use of future extensions of the structured field syntax. Support for future versions of SF will require an update to this specification." I believe this matches what NAME suggested.
Except that your proposed text is incorrect. The implication you are drawing is not true, nor what others have taken from that text. The use of the parameter does not preclude extensions to RFC 8941, as has been discussed at length here and on the mailing list. Extensions to sf types would not require changes to the signatures spec. I propose closing this issue without change to the signatures spec.
Sorry. Mark asked me to propose text, and that's what I did. The text has a normative requirement to use an RFC8941 serializer, so the proposed text is correct. That we disagree here is proof that a clarification is needed. If you feel that that p.o.v.
Code change:
defined in DIGEST to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. <ins> The expected structured field types (STRUCTURED-FIELDS) of any required or expected covered component fields or parameters. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter of the signature parameters (signature-params) and define rules

Related discussion:
text: is too restrictive, we'll have to somehow relax the requirement on the serializer (for instance, by stating that the serializer needs to implement 8941 or a successor RFC - that is an RFC that obsoletes 8941). FWIW, I agree that this would be good. But it is not what the spec says.
No, we reference the current document and if that document is updated or obsoleted by something else after publication then you as an implementer go and follow that. That's how updating RFC's already work. All the specs and systems that implemented RFC2616 didn't suddenly break and become invalid when 7230 or later 9110 came out. Here, It's up to the updaters of 8941 to make sure there's A serialization section. Your view of specification dependency is not at all in line with reality.
I see where you're coming from; I'd appreciate if you would do the effort to understand where I'm coming from. The difference here is that any spec that extends 8941 with new types by definition is not backwards compatible. This is because 8941 has no extension points, has drastic error handling and thus requires a wholesale spec update for new things. This is very different from most other RFCs that we're using here. If there is agreement about what we want, why don't we just say it?
To illustrate further: RFC8941-vs-8941bis is like XML1.0-vs-1.1 or HTTP1.1-vs-2.0, not like RFC2616-vs-RFC9112.
That's a very specific definition of 'not backwards compatible' and one that I suspect many would be surprised by. Just because there are no explicitly nominated extension points doesn't mean you can't evolve the specification in a backwards-compatible fashion; the key requirement is that valid inputs per the 'old' version are also valid inputs per the 'new' revision. That is the case for sf-bis. It is true that an invalid input for RFC 8941 will now become valid; specifically, a type value beginning with 'NAME used to generate an error, and now will not (provided that the following characters are appropriate). The reasonable question to ask at this point is whether it's realistic / probable that an application will be depending upon that error being thrown to operate.
Code change:
defined in DIGEST to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. <ins> The expected structured field types (STRUCTURED-FIELDS) of any required or expected covered component fields or parameters. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter of the signature parameters (signature-params) and define rules

Related discussion:
text: Can you suggest when that might be the case? Because I find it doubtful in the extreme that this will cause real-world problems.
I agree that this wouldn't cause real-world problems. I just also wish that our specs actually say what we think should happen, instead of requiring people to figure out. So in this case, I think we can solve this by saying "RFC 8941 or a revision obsoleting it".
Since NAME acknowledges that this doesnt affect interoperability and this is merely a "wish", NAME why don't you go ahead and incorporate your proposal so we can ship this spec?
NAME - please don't claim what I said something I did not say. My position remains: the spec should be clear about what it expects implementers to do. Right now it is not. If the agreement is "use RFC 8941 or a future revision", why don't we say that?
Proposed change: URL
Code change:
designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.4. </del> <ins> 3.1.3. </ins> When multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows. <del> 3.1.5. </del> <ins> 3.1.4. </ins> (TODO: Discuss short and long flows)

Related discussion:
text: Reverts ietf-wg-ccwg/rfc5033bis. This was accidentally submitted without review. The conclusion of the editors is that this is out of scope for the document.
Code change:
header field is received, by the target URI. The 201 response content typically describes and links to the <del> resource(s) created.  See response.validator for a discussion of the meaning and purpose of validator fields, such as and , in a 201 response. </del> <ins> resource(s) created.  Any validator fields (response.validator) sent in the response convey the current validators for a new representation created by the request.  Note that the PUT method (PUT) has additional requirements that might preclude sending such validators. </ins> 15.3.3.

Related discussion:
text: … (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.
Code change:
4.1.1.1. During registration, a Transparency Service MUST, at a minimum, <del> authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its currently configured trust anchors, using the "x5t" (34), "x5chain"(33) or "kid"(4) protected headers of the Signed Statement as hints.  For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by "x5t", to one of the root certificates most recently registered as a trust anchor of the Transparency Service. </del> <ins> syntactically check the Issuer of the Signed Statement by cryptographically verifying the COSE signature according to RFC9052. The Issuer identity MUST be bound to the Signed Statement by including an identifier in the protected header. If the protected header includes multiple identifiers, all those that are registered by the Transparency Service MUST be checked. For instance, when using X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by "x5t", to one of the root certificates most recently registered as a trust anchor of the Transparency Service. </ins> The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of

Related discussion:
text: Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".
Code change:
The following terms are defined in this document: <del> Network Incident: An unexpected interruption of a network service, degradation of network service quality, or sub-health of a network service TMF724A. Problem: The cause of one or more incidents.  The cause is not usually known when a problem record is created, and the problem management process is responsible for further investigation TMF724A. Incident management: Lifecycle management of incidents including incident identification, reporting, acknowledge, diagnosis, and resolution. Incident management system: An entity which implements incident management.  It include incident management server and incident management client. Incident management server: An entity which provides some functions of incident management.  For example, it can detect an incident, perform incident diagnosis, resolution and prediction,etc. Incident management client: An entity which can manage incidents. For example, it can receive incident notifications, query the information of incidents, instruct the incident management server to diagnose, resolve, etc. </del> 3. 3.1. <del> Traditionally, the dispatching of trouble tickets is mostly based on alarms data analysis and need to involve operators' maintenance engineers.  These operators' maintenance engineers are able to monitor and detect that alarms at both end devices of specific network tunnel or at both optical layer and IP layer which are associated with the same network fault.  Therefore, they can correlate these alarms to the same trouble ticket, which is in the low automation.  If there are more alarms, then the human costs for network maintenance are increased accordingly. </del> <ins> Usually, the dispatching of trouble tickets is mostly based on alarms data analysis and need to involve operators' maintenance engineers. These operators' maintenance engineers are able to monitor and detect that alarms at both end devices of specific network tunnel or at both optical layer and IP layer which are associated with the same network fault.  Therefore, they can correlate these alarms to the same trouble ticket, which is in the low automation.  If there are more alarms, then the human costs for network maintenance are increased accordingly. </ins> Some operators preconfigure whitelist and adopt some coarse granularity data correlation rules for the alarm management.  It

Related discussion:
text: We remove incident type yang model, so the number of yang modules we proposed is reduced from 2 into 1. So I think the text still needs some tweak, besides this, all good changes.
Code change:
largest Group ID for this track.  This field is only present if ContentExists has a value of 1. <ins> Subscribe Parameters: The parameters are defined in version- specific-params. </ins> 6.13. A publisher sends a SUBSCRIBE_ERROR control message in response to a

Related discussion:
text: Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM
Code change:
Consumers want to assess whether to trust a promoter or not (4.3.4) <del> To be continued... </del> <ins> Consumers and other stakeholders in the system wants to verify the claims made by a software supplier by recreating the build environment to ascertain that the delivered binary is precisely the same one as claimed by the supplier </ins>

Related discussion:
text: Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!
Code change:
Consumers want to assess whether to trust a promoter or not (4.3.4) <del> To be continued... </del> <ins> Consumers and other stakeholders in the system wants to verify the claims made by a software supplier by recreating the build environment to ascertain that the delivered binary is precisely the same one as claimed by the supplier </ins>

Related discussion:
text: NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements
Code change:
SCITT architecture focuses on ensuring statement authenticity, visibility/transparency, and intends to provide scalable accessibility.  The following use case illustrates the scope of SCITT <del> and elaborate on the generic problem statement above. </del> <ins> and elaborates on the generic problem statement above. </ins> 3.

Related discussion:
text: Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.
Code change:
1.4. <del> HTTP Message Signatures are designed to be a general-purpose security mechanism applicable in a wide variety of circumstances and applications.  In order to properly and safely apply HTTP Message Signatures, an application or profile of this specification MUST specify all of the following items: </del> <ins> HTTP Message Signatures are designed to be a general-purpose tool applicable in a wide variety of circumstances and applications.  In order to properly and safely apply HTTP Message Signatures, an application or profile of this specification MUST specify at least all of the following items: </ins> The set of covered-components and signature-params that are expected and required to be included in the covered components

Related discussion:
text: message signatures are just one part of an overall system, and this adds language to make that expectation more explicit in the introductory sections.
Code change:
be safely retried using a new connection. Activity on streams numbered lower or equal to the last stream <del> identifier might still complete successfully.  The sender of a GTFO frame might gracefully shut down a connection by sending a GTFO </del> <ins> identifier might still complete successfully.  The sender of a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY </ins> frame, maintaining the connection in an open state until all in- progress streams complete.

Related discussion:
text: This is almost a straight revert of the various GOAWAY -> GTFO changes. It seems like this is the popular move as per the discussion on the httpbis mailing list. Arguments for the revert: GOAWAY is self-descriptive and serves it purpose well. Editorial changes that don't clearly improve the spec should be discouraged so we can reach a stable spec sooner (granted this change doesn't affect the wire at all, but documentation churn counts too). GTFO is crass and doesn't belong in internet standards. GTFO, if it really stands for "General Termination of Future Operations," has a surprising definition and may produce confusion. We should strive for absolute clarity above all else in editorial changes.
Boo! You guys are no fun.
goaway is just as bad as gtfo for the same reasons as the argument against gtfo... just called it disconnectclient or endcommunication if you're going to be a grumplestiltskin.
QUENCH may be a better, more descriptive word that has been used before in RFC's (for TCP Source Quench messages)
I think we should call it BIKESHED. , Sean McElroy EMAIL:
Here we go.. useless HN circle jerk.
:cat2:
How about STFU?
Boo!
:-1:
This commit should be reverted. It's time we stop behaving like oversensitive automatons and display the beautiful human quality that is a sense of humor every once in a while.
^ this
^ that
how about something like PLZSTOP? it's slightly humorous, but it actually reflects what is wanted (if I understood the spec correctly)
GOAWAY is clearer for non-native English speakers, easier to pronounce, and more professionally appropriate than the common connotational definition of GTFO. There are times and places for pushing the boundaries of professional speech, but the HTTP2 spec isn't one of them.
At least the pendulum didn't swing the other way NICETALKINGTOYOU
This revert is for the express purpose of stopping endless bikeshedding. We shouldn't encourage trivial changes to frame names. If the name is good enough, it should stay. I'm all for fun and games, but clarity and concision (as well as spec stability) come first.