jiebi/CodeConvo huggingface dataset:
Code change:
Given a float as input_float: <del> If input_float is not a IEEE 754 double precision number, fail serialisation. </del> <ins> If input_float's fractional part has more than six digits of precision, fail serialisation. If the number of digits of precision in input_float's fractional part plus those in its integer part add to more than fifteen digits, fail serialisation. </ins> Let output be an empty string.

Related discussion:
text: I've read the IETF105 minutes, and thought about the fixed-point discussion. All the uses for "decimal number with fractional part" I can think of\ would reasonably served by at least 10 digits to the left\ and at least 3 to the right of the point. So I would support any fixed- or floating-point representation that supports that range of values. \ that's all that matters, right? \ a ten-decimal-digit time_t gives us until November 20, 2286
Using the max-six-decimal definition, and allowing 15 digits with no period or decimals, this C-code will do the job: static char * sh_float(double d) { static char buf[40]; int n; if (fabs(d) < 1000000000) { n = snprintf(buf, sizeof(buf), "%f", d); while (buf[--n] == '0') buf[n] = '\0'; if (buf[n] == '.') buf[n] = '\0'; } else { n = snprintf(buf, sizeof(buf), "%.15g", d); } return (buf); }
Sorry, wrong button.
If I take , then I can almost represent that in a JS float in the most horrific way imaginable: But that doesn't quite fit. 69999999999999999 doesn't fit into a double. If you want to remember the number of additional decimal places so that you don't lose any precision on those trailing decimal places (things like 0.3 are surprisingly tricky to re-encode), you are left with supplementary values. Can someone make a better case for any more than 10^10 values here? I couldn't see a good one. You can fit a 32-bit value in that. If you really think that time_t is valuable, which I'm totally not convinced of, then fewer steps might be acceptable. I can pack this:
PR updated. Any further comments, or ready to merge?
Code change:
the user in order to convince them to grant authorization on the Authorization Device.  The attacker is able to change the context of the authorization request because the channel between the Initiating <del> Device and the Authorizing Device is unauthenticated.  These attacks are also known as Cross-Device Consent Phishing (CDCP) attacks. </del> <ins> Device and the Authorization Device is unauthenticated.  These attacks are also known as Cross-Device Consent Phishing (CDCP) attacks. </ins> 3.1.

Related discussion:
text: The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.
Code change:
fig-transparent-statement-cddl illustrates a normative CDDL definition of Transparent Statements. <del> fig-transparent-statement-edn illustrates a payload that is detached. The unprotected header can contain multiple receipts. </del> <ins> fig-transparent-statement-edn illustrates a Transparent Statement with a detached payload, and two receipts in its unprotected header. The label 394 "receipts" in unprotected header can contain multiple receipts. </ins> <del> Notice the verifiable data structure used is RFC9162_SHA256 in this case.  We know from the COSE Verifiable Data Structure Registry that RFC9162_SHA256 is value 1, and that it supports -1 (inclusion proofs) and -2 (consistency proofs). </del> <ins> fig-receipt-edn one of the decoded Receipt from fig-transparent- statement-edn.  The Receipt contains inclusion proofs for verifiable data structures.  The unprotected header contains verifiable data structure proofs.  See the protected header for details regarding the specific verifiable data structure used.  Referencing the COSE Verifiable Data Structure Registry, RFC9162_SHA256 is value "1", which supports "-1" (inclusion proofs) and "-2" (consistency proofs). </ins> <del> Notice the unprotected header contains verifiable data structure proofs, see the protected header for details regarding the specific verifiable data structure used. </del> <ins> fig-receipt-protected-header-edn illustrates the decoded protected header of the Transparent Statement in fig-transparent-statement-edn. The verifiable data structure ("-111") uses "1" from (RFC9162_SHA256). </ins> <del> This is a decoded inclusion proof for RFC9162_SHA256, other verifiable data structures might encode inclusion proofs differently. </del> <ins> fig-receipt-inclusion-proof-edn illustrates the decoded inclusion proof from fig-receipt-edn.  This inclusion proof indicates that the size of the transparency log was "8" at the time the receipt was issued.  The structure of this inclusion proof is specific to the verifiable data structure used (RFC9162_SHA256). </ins> <del> 4.3.1. </del> <ins> 4.4.1. </ins> Relying Parties MUST apply the verification process as described in <del> Section 4.4 of RFC9052. </del> <ins> Section 4.4 of RFC9052, when checking the signature of Signed Statements and Receipts. A Relying Party MUST trust the verification key or certificate and the associated identity of at least one issuer of a Receipt. A Relying Party MAY decide to verify only a single Receipt that is acceptable to them, and not check the signature on the Signed Statement or Receipts which rely on verifiable data structures which they do not understand. </ins> APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.  For example, an

Related discussion:
text: Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM
Code change:
3.1. <del> The HTTP/2.0 session runs atop TCP (RFC0793).  The client is the TCP connection initiator. </del> <ins> The HTTP/2.0 session is an Application Level protocol running on top of a TCP connection (RFC0793).  The client is the TCP connection initiator. </ins> HTTP/2.0 connections are persistent.  That is, for best performance, <del> it is expected that clients will not close connections until the user navigates away from all Web pages referencing a connection, or until the server closes the connection.  Servers are encouraged to leave connections open for as long as possible, but can terminate idle connections if necessary.  When either endpoint closes the transport- level connection, it MUST first send a GOAWAY frame so that the endpoints can reliably determine if messages were processed beforehand. </del> <ins> it is expected a clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page), or until the server closes the connection. Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the transport-level TCP connection, the terminating endpoint MUST first send a GOAWAY frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </ins> 3.2. <del> The first data sent on an HTTP/2.0 session - after opening a TCP connection and performing either an HTTP/1.1 Upgrade or TLS handshake - is a session header. The session header provides a final confirmation that both peers agree to use the HTTP/2.0 protocol.  The SETTINGS frame ensures that client or server configuration is known as quickly as possible. </del> <ins> Upon establishment of a TCP connection and determination that HTTP/2.0 will be used by both peers to communicate, each endpoint MUST send a session header as a final confirmation and to establish the default parameters for the HTTP/2.0 session. </ins> The client session header is a sequence of 25 octets (in hex notation)

Related discussion:
text: Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,
Code change:
3.2. <del> In HTTP/2 and HTTP/3, the client uses the proxy by issuing an "extended CONNECT" request as follows: </del> <ins> In HTTP/2 and HTTP/3, the proxy MUST include SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame RFC9220.  The client uses the proxy by issuing an "extended CONNECT" request as follows: </ins> The :method pseudo-header field SHALL be "CONNECT".

Related discussion:
text: The CONNECT-TCP draft makes informative references to other drafts which use "extended CONNECT" (CONNECT-UDP, CONNECT-IP), but does not have a normative reference to the draft which defines this use of the CONNECT method. It references the "extended CONNECT" method without supplying a reference for this term. This draft spells out the required values for each pseudo-header, but omits the requirement to set SETTINGSENABLECONNECT_PROTOCOL. A reference to RFCs 8441/9220 is probably needed, and a reminder that the method in this document can only be used if the server sends this setting first.
That'll do.
Code change:
8. <del> This document obsoletes the usage of parameters with "Digest" introduced in Section 4.1.1 and 4.2 of RFC3230 because this feature has not been widely deployed and complicates field-value processing. </del> <ins> Section 4.1.1 and 4.2 of RFC3230 defined field parameters.  This document obsoletes the usage of parameters with "Digest" because this feature has not been widely deployed and complicates field-value processing. </ins> <del> Field parameters provided a common way to attach additional information to a representation-data-digest, but if they are used as an input to validate the checksum, an attacker could alter them to steer the validation behavior. </del> <ins> RFC3230 intended field parameters to provide a common way to attach additional information to a representation-data-digest.  However, if parameters are used as an input to validate the checksum, an attacker could alter them to steer the validation behavior. </ins> <del> A digest-algorithm can still be parameterized defining its own way to encode parameters into the representation-data-digest in such a way as to mitigate security risks related to its computation. </del> <ins> A digest-algorithm can still be parameterized by defining its own way to encode parameters into the representation-data-digest, in such a way as to mitigate security risks related to its computation. </ins> 9.

Related discussion:
text: This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!
Code change:
FieldBlock. The total number of padding octets is determined by the value of the <del> Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </del> <ins> Pad Length field.  If the length of the padding is the length of the frame payload or greater, the recipient MUST treat this as a ConnectionErrorHandler of type PROTOCOL_ERROR. </ins> 6.3.

Related discussion:
text: by copying the text from DATA
says: I think the intended reading is that when the parser reaches the point that only the FBF and the Padding remain, the length of Padding is given by Pad Length and the fragment is the balance. If Pad Length exceeds the remaining length of the frame, it's an error. There is a less-likely reading also allowed by the current phrasing, that Pad Length can't be more than half the remaining bytes (else Padding would exceed the size of the field block fragment). That's very unlikely to be the intended reading, but we should be clear here. I'd suggest simply taking the note from the end of DATA and putting it here verbatim.
LGTM, will let NAME take a read as well.
Code change:
aliases" to indicate that no CNAME records were encountered when resolving the next hop's name. <ins> 2.1. DNS names commonly just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. For example, consider the DNS name "name,with,commas.example.com". This name would be encoded within a "next-hop-aliases" parameter as follows: It is also possible for a DNS name to include a period character (".") within a label, instead of as a label separator.  In this case, the period character MUST be first escaped as "\.".  Since the "\" character itself will be percent-encoded, the name "dot\.label.example.com" would be encoded within a "next-hop-aliases" parameter as follows: Upon parsing this name, "dot%5C.label" MUST be treated as a single label. Similarly the "\" character in a label MUST be escaped as "\\". Other uses of "\" MUST NOT appear in the label after percent- decoding. </ins> 3. In order to include the "next-hop-aliases" parameter, a proxy needs

Related discussion:
text: The "" set includes ".", but we actually need to escape "." to avoid attacks.
Hm, my impression is that this attack is about making a period within a label look like a label separator. By the time that you have a string for a name, it would already need this kind of escaping done. Put another way, the "." characters we have in the string are indeed label separators already.
The draft doesn't specify how to construct the DNS name string (and in general there is not a great specification for this). The most common convention (noted in RFC 1035 Section 5.1) is to precede "." inside a label with a backslash. This draft would then percent-escape the backslash, but not the ".", so there would indeed be a "." character that is not a label separator in the final header field value. Whatever escaping convention you choose, this is sufficiently non-obvious that I think a very clear specification and some examples are probably in order. (This whole rigmarole is normally not a problem because URIs are restricted to contain only "hostnames", which cannot have weird characters in the labels.)
NAME can you look at URL
I realize that this is now resolved, but isn't it also possible that we could say "this field cannot be used to express names that include a literal period (".") in labels" ?
NAME yeah that’s an option, although it could theoretically incentivize using dots in labels as a way to hide the CNAME from being reported
Sure. But you can add another attribute called "this-site-is-abusing-this-mechanism" for use when that happens.
Code change:
5. <del> This document makes no requests of IANA. </del> <ins> This section covers topics that are explicitly out of scope for the time being. 5.1. The creation of new media transport protocols should be avoided, and instead we should make use of RTP RFC3550 and the existing ecosystem of payload formats and methods of signalling where possible.  It may transpire a need to extend these specificiations; in which case we should work with the relevant working groups and present our use- cases. </ins> 6. <ins> This document makes no requests of IANA. 7. </ins> As this document is intended to create discussion and consensus and introduces no security considerations of its own. <del> 7.  References </del> <ins> 8.  References </ins> <del> 7.1.  URIs </del> <ins> 8.1.  URIs </ins> [1] https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing- moq-requirements

Related discussion:
text: NAME I could also include some other non-requirements into the section if you have some to mind.
A similar section seemed helpful during discussion of URL My first nominee (and I'll put that in the corresponding PR) is that we're assuming that we're working with existing media transport protocols like RTP and SRP, rather than inventing a new media transport protocol in the IETF, but we can talk when I have text.
We have this in place, and I think we have enough non-requirements to start with, let's keep adding as appropriate.
Code change:
In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Key Binding. <del> 10.11. </del> <ins> 10.10. </ins> In a Presentation, the Issuer-signed JWT is integrity-protected by the Issuer's signature, and the Disclosures are integrity-protected

Related discussion:
text: Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text
Code change:
If the client has no knowledge of whether the resource supports resumable uploads, the Upload Creation Procedure MAY be used with <del> some additional constraints.  In particular, the "Upload-Incomplete" header field (upload-incomplete) MUST NOT be set to true if the server support is unclear.  This allows the upload to function as if it is a regular upload. </del> <ins> some additional constraints.  In particular, the "Upload-Complete" header field (upload-complete) MUST NOT be set to false if the server support is unclear.  This allows the upload to function as if it is a regular upload. </ins> The server SHOULD send the "104 (Upload Resumption Supported)" informational response to the client, to indicate its support for a

Related discussion:
text: Closes URL
NAME brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don’t mean exactly the same thing: on the server means it has received the full upload, while on the client means the body it will send is a complete upload.
We discussed this internally and prepared a response: Upload-Complete is used on both requests and responses because it is symmetrical. Upon a typical successful transaction, an request results in an response, and an request results in an response. A server implementation can simply echo the field. However, they are also meanings that we can take advantage of. The presence on the request means it’s a resumable request, and the presence on the response is also a useful signal. Since we are upgrading regular uploads, there are cases where 4xx/5xx responses are intentional and we can't just eat it by attempting to resume. We would be much more confident that the response came from the real server rather than a middlebox which shouldn’t randomly add . The server can also use to terminate a request early if it does not care about the body, similar to the early response mechanism in HTTP/3.
I am having second thoughts about this as well. While debugging a server implementation, the naming of the headers also confused me for a moment (even though I wrote parts of the draft). The reason is that in a response (or how it is currently called) refers to the current state of the upload, while in a request refers to the potential state in the future, if the request completed successfully. I don't think that we have a general issue with the concept of and have to change much. But maybe a simple name change can help here already to alleviate the confusion. We could use for the response header to indicate that it represents the current state. And for request headers to indicate that process the request successfully will complete the upload. We loose the symmetry of the names in request and response, but maybe this makes their relation even clearer.
I think for both client and server works because it represents their own perspectives of the upload. For the client, sending means "the upload is complete on my end, I've included all the data to complete it."
Code change:
If the client has no knowledge of whether the resource supports resumable uploads, the Upload Creation Procedure MAY be used with <del> some additional constraints.  In particular, the "Upload-Incomplete" header field (upload-incomplete) MUST NOT be set to true if the server support is unclear.  This allows the upload to function as if it is a regular upload. </del> <ins> some additional constraints.  In particular, the "Upload-Complete" header field (upload-complete) MUST NOT be set to false if the server support is unclear.  This allows the upload to function as if it is a regular upload. </ins> The server SHOULD send the "104 (Upload Resumption Supported)" informational response to the client, to indicate its support for a

Related discussion:
text: The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.
Code change:
Track Request Parameters: The parameters are defined in track-req- params. <del> 6.6.1. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. 6.6.1.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </del> 6.7. The receiver sends an "ANNOUNCE OK" control message to acknowledge

Related discussion:
text: This PR moves track request params to its own section. This was messed up during huge PR merge as part of preparing for IETF117 work. Also it add track namespace length field to Announce_OK message which was omitted.
NAME good catch. updated the commit to address your comment. Thanks
It's an improvement so we should merge, but we do need to clean up how parameters are encoded.You may also want to move the actual definition of Track Request Parameter, it's currently in the SUBSCRIBE REQUEST section.