jiebi/CodeConvo huggingface dataset:
Code change:
HTTP depends on the security properties of the underlying transport- or session-level connection to provide confidential transmission of <del> fields.  In other words, if a server limits access to authenticated users using this framework, the server needs to ensure that the connection is properly secured in accordance with the nature of the authentication scheme used.  For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", RFC8446) prior to exchanging any credentials. </del> <ins> fields.  Services that depend on individual user authentication require a connection prior to exchanging credentials (https.uri). </ins> 17.15.2.

Related discussion:
text: " For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", [RFC8446]) prior to exchanging any credentials." This originates from RFC 7235. Nowaday, shouldn't we instead say "require HTTPS"?
I think it should be ... authentication require a secured connection prior to exchanging any credentials (ref target="URL"). and x:ref around the term "secured" (defined in that section).
Code change:
the presence of authentication to observers due to clear-text TLS Client Hello extensions. <ins> Since the freshness described above is provided by a TLS key exporter, it can be as old as the underlying TLS connection.  Servers can require better freshness by forcing clients to create new connections using mechanisms such as the GOAWAY frame (see H3). </ins> The authentication proofs described in this document are not bound to individual HTTP requests; if the key is used for authentication proofs on multiple requests on the same connection, they will all be

Related discussion:
text: In Section 8: Given that the exporter can be produced at any point in the lifetime of a TLS connection and that TLS connections can remain open for a very long time, it's not clear that this guarantees freshness in the same way that a nonce does. It might be clearer to state that it guarantees the authenticator is no older than the beginning of the current TLS connection. (I presume that a server can use GOAWAY to get rid of connections it considers unacceptably old.)
Code change:
the ULA link prefix. A failure to renew the DHCPv6-PD-provided OSNR prefix could be <del> because the SNAC network has been disconnected from one AIL and moved </del> <ins> because the stub network has been disconnected from one AIL and moved </ins> to a different AIL.  In this situation, if the new AIL also has IPv6 service and DHCPv6-PD service, the DHCPv6 client will get a clear indication that the old prefix is no longer valid.  However, it may be that no DHCPv6-PD service is available on the new link, either because it is an IPv4-only link or because it's an IPv6-capable link <del> that doesn't provide DHCPv6 service.  In this situation, if the SNAC </del> <ins> that doesn't provide DHCPv6 service.  In this situation, if the stub </ins> network remains connected to the link and no DHCPv6 service appears, the DHCPv6-PD-provided OSNR prefix will eventually time out and be replaced.  The SNAC router SHOULD NOT attempt to replace it prior to this normal timeout process, because there is no benefit to changing <del> the OSNR prefix on the SNAC network in such a situation, and it's </del> <ins> the OSNR prefix on the stub network in such a situation, and it's </ins> possible that the SNAC router will return to the other link before the OSNR prefix expires.

Related discussion:
text: As Esko pointed out, the term "SNAC network" crept in during editing a few weeks ago, and doesn't add value. This pull request changes all instances of "SNAC network" to "stub network".
In -05, the term "SNAC network" is now used but not defined. Could we use the more generic term "stub network" instead? I.e. a SNAC router is able to automatically connect a stub network to an infrastructure network. So the stub network served by this SNAC router is still a "stub network". Or we could use the term "SNAC network" for any stub network that gets automatically connected via a SNAC router. But doing this adds an extra term throughout the document: it's not possible to mass-replace all occurrences of "stub network".
See also which overlaps with this issue, but targets a specific definition paragraph.
Right, this happened when we added a bunch of text in the last interim, and I think was a mistake. I think we just want to use the term "stub network" and not invent a new term. The thing that's new here is the "SNAC router", not the stub network.
I agree - "stub network" makes more sense here.
removed
Code change:
Artifacts, from the build and supply of software and IoT devices to advanced manufacturing and food supply. <del> SCITT is a generalization of Certificate Transparency RFC9162, which can be interpreted as a transparency architecture for the supply chain of X.509 certificates.  Considering CT in terms of SCITT: </del> <ins> SCITT is a generalization of Certificate Transparency (CT) RFC9162, which can be interpreted as a transparency architecture for the supply chain of X.509 certificates.  Considering CT in terms of SCITT: </ins> <del> CAs (Issuers) sign X.509 TBSCertificates (Artifacts) to produce X.509 certificates (Signed Statements) </del> <ins> CAs (Issuers) sign the ASN.1 DER encoded tbsCertificate structure to produce an X.509 certificate (Signed Statements) </ins> CAs submit the certificates to one or more CT logs (Transparency Services)

Related discussion:
text: removed "(Artifact)" which seems to have been an artifact....LGTM
Code change:
sufficiently backwards-compatible to be safely processed by any implementation of the same major version. <ins> 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. </ins> 4. Each major version of HTTP defines its own syntax for the inclusion

Related discussion:
text: HTTP defines its own protocol versions as having two numbers "URL" regardless of anyone's future opinions on the subject. This is necessary for Via and Upgrade. In the past, it has always been assumed that no document claiming to define a version of HTTP would ignore that fact. Regardless, HTTP/1.1 needs to refer to future versions of HTTP within the scope of its own syntax. Hence, the following text (currently in crefs) has been suggested for the last paragraph of the section "Protocol Versioning" in Semantics.
SGTM
Why "ought to be used"? I understand that you want to avoid MUST/SHOULD,..., but why not just "is used"? That would make it:
+1, let's limit the RFC6919 language. You're defining a mapping between formats, not really adding new normative or moral requirements. The "0" is simply how a major-only version is rendered in a URL field.
The background here is that we used 'ought' liberally in 723x (e.g., 49 times in 7231) to give implementers guidance towards good behaviour without affecting conformance for existing deployments. So this is entirely in the spirit of the existing specifications.
That use is often appropriate. In this case, the conditions are such that "is" works. It is also more assertive, which works.
all: try and do your best to focus on the substance of the question rather than the editorial wrappings. Thanks.
The substance of the question is obvious, in my opinion. I'd question whether there's a need for discussion on that. However, the editorial wrappings do actually matter in having the final document communicate what we want it to communicate. It's feedback I'd typically give on a PR rather than the issue, but in this case the issue contains proposed text, so the editorial feedback is here too.
Agree with Mike. I came to this issue almost by chance, I thought it was important because Julian wrote a mail to the mailing list. When I had a look at the issue, the only thing that caught my eye was the "ought", because the substance is indeed obvious (at least to me). If "ought" is used liberally in 723x, there may be good reasons for it, and in many places it may make sense.
Code change:
sufficiently backwards-compatible to be safely processed by any implementation of the same major version. <ins> 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. </ins> 4. Each major version of HTTP defines its own syntax for the inclusion

Related discussion:
text: But I'd ask the editors to go through these 49++ times and see if it wouldn't be possible to replace some of them with "is". "is" just reads so much more easily where it's appropriate than "ought".
Code change:
4.1.1.2. <ins> Given an ordered dictionary parameters: Let output be an empty string. For each parameter in parameters: Append ";" to output. Let name be the result of applying Serializing a Key (ser-key) to parameter's param-name. Append name to output. If parameter has a param-value: Let value be the result of applying Serializing an Item (ser- item) to parameter's param-value. Append "=" to output. Append value to output. Return output. 4.1.1.3. </ins> Given a key as input_key: If input_key is not a sequence of characters, or contains

Related discussion:
text: Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.
Code change:
named field as defined in HTTP.  The field value MUST be taken from the named header field of the target message unless this behavior is overridden by additional parameters and rules, such as the "req" and <del> "tr" flags, below. </del> <ins> "tr" flags, below.  For most fields, the field value is an ASCII string as recommended by HTTP, and the component value is exactly that string.  Other encodings could exist in some implementations, and any characters outside the ASCII range MUST be encoded using the percent-encoding mechanism defined in URI. </ins> Unless overridden by additional parameters and rules, HTTP field values MUST be combined into a single value as defined in HTTP to

Related discussion:
text: Addresses encodings of signature component values for query parameters and field values.
: This seems to be inconsistent with Section 2.2.8 ("Query Parameters"), which could create non-ASCII component values.
FWIW, a query parameter (after application of URL) could contain CR, LF and other control characters.
So we likely need to serialize information extracted from query parameters using some kind of encoding; maybe an SF Byte Sequence.
This is tricky -- originally the query parameters were kept in percent-encoded form but from WG discussion we changed that to just use the unencoded value instead since several percent-encoded forms could be used. However it does look like the unencoded form could end up with problematic values here, so maybe we need to go back to that. I'd rather us use an encoding native to the value rather than inventing something to put on top of it, even trying to re-use the flag we've already got defined for headers.
And we did that because to extract query parameter values, we need a query parser, and that is defined the way it is. I believe that decision was good, we now just need to figure out out to transform the extracted values so that they can be used in the signature base. (And, FWIW, at the end we also should have an example for a case like that in the spec).
In 2.2.8, it might be good to mention that the referenced algorithm only supports query parameters using (percent-escaped) UTF-8 encoding (this came as a surprise to me because I assumed it works the same as the algorithm used for forms decoding).
in 2.1.3: What if the field value contains non-ASCII characters (from obs-text)? Of course that could be considered an error, but I believe the intention is to be able to represent anything here. So the text should refer to the field value as byte sequence, in which case the encoding step would not be needed.
This text was added in response to a comment about needing to know which encoding to put into the byte sequence input, and the commenter suggested ASCII as the base for it. If field values have a well-defined byte sequence that isn't ASCII characters only, then we should refer to whatever that is from the HTTP docs.
Well, field values in HTTP can be anything. It's obsolete, it's deprecated, but that's what it is.
Code change:
named field as defined in HTTP.  The field value MUST be taken from the named header field of the target message unless this behavior is overridden by additional parameters and rules, such as the "req" and <del> "tr" flags, below. </del> <ins> "tr" flags, below.  For most fields, the field value is an ASCII string as recommended by HTTP, and the component value is exactly that string.  Other encodings could exist in some implementations, and any characters outside the ASCII range MUST be encoded using the percent-encoding mechanism defined in URI. </ins> Unless overridden by additional parameters and rules, HTTP field values MUST be combined into a single value as defined in HTTP to

Related discussion:
text: So we need to deal with it one way or another. I could live with UTF-8, and a note that if the octet sequence does not decode as UTF-8, you can't sign it.
NAME - yes, you can merge and close issues as you wish, you are the editor. But by all means do not submit a new draft until the changes have been reviewed by those who opened the issue. (cc chairs NAME NAME )
As far as I can tell, the changes require percent-encoding only for non-ASCII values. That is, the character U+0080 would get the same encoding as a verbatim "%80" in a field value. I believe this is a problem.
This issue has been addressed. There is no percent encoding needed in this section since the value is taken directly from the bytes of the field in a binary-wrapped representation, and the bytes are encoded using the base64 serialization of a Byte Sequence from Structured Fields:
I'm talking about the simple case, not the one where Byte Sequence encoding is used (yes, the issue title doesn't match anymore).
Ok, opened new issue URL
Code change:
Body: SCITT COSE_Sign1 message <del> 2.1.1.2. </del> <ins> 2.2.1.2. </ins> One of the following:

Related discussion:
text: Strawman proposal for: URL PoC implementation here URL
Definite start in the right direction - I would say it is enough to get in and build on
general thumbs upLGTM After a chat with Richard Barnes, I think there are a few things happening with and key binding, that we should probably consider independently for scitt: Registration Policies that require fresh signatures from issuers. Registration Policies that require issuer's to commit to a recent tree head. Registration Policies that require additional context binding and a fresh signature from the issuer bound to special context. 1 and 2 are basically both about "time". If the Transparency Service does not trust the issuer to be honest about time, the transparency service can force the issuer to include a time commitment from the transparency service in their registration with binding to their confirmation public key. In the case the "nonce" is a timestamp, the TS rejects key binding tokens that are outside some window. In the case the "nonce" is a recent tree head, the TS rejects key binding tokens that are not to a tree head inside some window. In the case the "nonce" is a "challenge token", the nonce is some special context, the TS rejects key binding tokens that lack this special context. There is an opportunity to make the registration none interactive and one shot, assuming the following is acceptable: The key binding token nonce is a "recent timestamp / tree head" The transparency service rejects key binding tokens with nonces that are not "recent" There is an opportunity to make the registration interactive and context binding, assuming the following is acceptable: The transparency service includes specific context the issuer must commit to in their "challenge token". The issuer uses the challenge token as the nonce in their key binding token. The transparency service rejects key binding tokens with nonces that omit required context In this second case, imagine a "dynamic registration policy" Holder (Issuer) asks Verifier (Transparency Service) for a challenge token for a Customs Entry for 16056100.
Code change:
Body: SCITT COSE_Sign1 message <del> 2.1.1.2. </del> <ins> 2.2.1.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:
Promised requests MUST be cacheable (see RFC7231), MUST be safe (see RFC7231) and MUST NOT include a request body.  Clients that receive a <del> promised request that is not cacheable, unsafe or that includes a request body MUST reset the stream with a StreamErrorHandler of type </del> <ins> promised request that is not cacheable, is not known to be safe or that indicates the presence of a request body MUST reset the promised stream with a StreamErrorHandler of type </ins> <del> . </del> <ins> .  Note this could result in the promised stream being reset if the client does not recognize a newly defined method as being safe. </ins> Pushed responses that are cacheable (see RFC7234) can be stored by the client, if it implements an HTTP cache.  Pushed responses are

Related discussion:
text: New safe methods can be defined. Does this mean that the client needs to respond with a stream error for methods not known to be safe? See URL
That would be the only logical conclusion. If the client cannot determine if the method is safe, it must assume that it is not.
Indeed. We just need to fix it.
Code change:
11.1. <del> The Privacy Considerations in Section 12.5 of I-D.ietf-oauth- </del> <ins> The Privacy Considerations in Section 10.1 of I-D.ietf-oauth- </ins> selective-disclosure-jwt apply especially to the claim.

Related discussion:
text: Remove the requirement to insert a .well-known part for vct URLs , ,
Dr. Fett, PhD: >Gentlemen, Some feedback I received (on top of the comments we already got in the issuers) makes me second-guess the choice to use a .well-known URL for the type metadata documents. In fact, RFC 5785 tells us that .well-known is mainly to be used for site-wide information or information about a specific host. that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata. Brian Campbell, B.A.: >That feedback seems not wrong to me. We've got probably a lot of somewhat questionable uses of .well-known but type metadata is maybe less well suited than most. And less needed. >It could just point to the json document. Or we make up some convention. Or something with uri templates.
Relevant related issues: , ,
I believe that lifting the restriction is not preventing the use of .well-known; IMO there are two approaches provide the full link signal that the metadata is under the well-known However, metadata owner must be aware of the responsibility to take care of the versioning. As mentioned in , should there be a requirement to either use hash links or protect the remote content via vct#digest? Dr. Horvat, PhD
Maybe I'm missing something, but the change in PR should mostly solve this, I think. It now requires to provide the full URL to the metadata. (If someone wants to provide it under .well-known, that is their choice, but doesn't influence the requester at all). For versioning I filed a . Not sure about making #digest mandatory, but we should also discuss this separately.
digest mandatory, but we should also discuss this separately. -> if it's an external resource, it should be defined how it is protected
URL Is defining that if vct is an https:// it should check the metadata under the well known (at least the 2nd part of the text reads like this: Many registries are, and will be accessible via URLs, hence the metadata type is expressed via an URL; Adding or maintaining a .well-known might not fit in the existing API designs.