jiebi/CodeConvo huggingface dataset:
Code change:
algorithm is used, i.e., the document is not signed. <del> In any case, the result is encoded as described in RFC7515 (here for </del> <ins> In any case, the result is encoded as described in RFC7519 (here for </ins> Example 1): (Line breaks for presentation only.)

Related discussion:
text: reflecting conversation in Issuer why we are not hiding claim names
I propose to move this to the privacy considerations.
makes sense.
Some use cases may require hiding both claim names and claims. Some schemas are country/jurisdiction-specific and revealing all claims might reveal some additional information. Open questions/remarks since the issuer is known, information about the schema can be guessed hiding the claim names does not hide the structure do use cases really require hiding the claim name?
There have been some discussions about it on the signal group. Just recording them for the transparency purposes hide claim values only hide claim names and claim values Rationale: Some schemas are country/jurisdiction specific and revealing all claims might reveal some additional information. (Something the use-cases still need to clarify is the fact that the issuer is known. Still waiting for some additional feedback.) That's what I thought. Another question would be: For structured claim objects (cf. eKYC & IDA Spec), do we need to hide the structure? The structure itself might be revealing some information. I can imagine the cases where an issuer would be issuing only one type of credentials with fixed structure and claimset. That means, if you know the issuer, you can pretty much find out the structure and claim names in it. So, hiding the structure and claim names would not add much. I would assume that is the default. I agree In ekyc, the structure alone can reveal the type of evidence used, which might leak info about e.g. nationality. But these cases might be rare and I'd also like to keep it simple for now. Right. At the same time, you typically want to know the nationality in the case of EKYC in financial institutions :-) Speaking of that, I was assuming that in a lot of cases, the receiver may need to know the type of credential especially when the issuer was issuing multiple types of credentials at different assurance levels. Is this assumption bogus? That's a valid assumption. Verifier needs to know the level of assurance of the VC and in most cases (I guess) it will need to know under what policies the holder keys are created/stored/... (or if it can trust the wallet where the Verifiable Presentation was created and is shared from)
NAME are you arguing to have both options - to hide and not to hide claim names?
Code change:
algorithm is used, i.e., the document is not signed. <del> In any case, the result is encoded as described in RFC7515 (here for </del> <ins> In any case, the result is encoded as described in RFC7519 (here for </ins> Example 1): (Line breaks for presentation only.)

Related discussion:
text: We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.
Code change:
algorithm is used, i.e., the document is not signed. <del> In any case, the result is encoded as described in RFC7515 (here for </del> <ins> In any case, the result is encoded as described in RFC7519 (here for </ins> Example 1): (Line breaks for presentation only.)

Related discussion:
text: In some use cases of SD-JWT, the key for what we currently call Holder Binding may not be bound to a holder (but, for example, to a device). We should therefore consider renaming Holder Binding to Key Binding.
PRs have been merged
The spec currently does not contain a reference for RFC 7519 (JWT), which it clearly needs to. It also uses RFC 7515 (JWS) as the citation for JWT in several place, which is incorrect. Please add a RFC 7519 (JWT) reference and cite it the first time that the term JSON Web Token (JWT) is used in the body of the spec (but not in the abstract). And look at the current uses of RFC 7515 and correct those that should be RFC 7519.
Code change:
5.1. An SD-JWT has a JWT component that MUST be signed using the Issuer's <del> private key.  It MUST use a JWS asymmetric digital signature algorithm.  It MUST NOT use </del> <ins> private key.  It MUST NOT use the </ins> <del> or an identifier for a symmetric algorithm (MAC). </del> <ins> algorithm. </ins> The payload of an SD-JWT is a JSON object according to the following rules:

Related discussion:
text: This addresses Issue . The rest of the text still refers to asymmetric signatures, but technically, an HMAC is now allowed.
The scope of this PR was intentionally to only remove the explicit prohibition on MAC. Not to explain how it might work or adjust other language about asymmetric signatures or private keys or similar. Just remove the explicit prohibition so that, should some deployment/ecosystem/jurisdiction need to MAC for whatever reason, it's not directly going against a normative must.
Code change:
HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". <ins> Note: Previous versions of this specification required that only one Cookie header field be sent in requests.  This is no longer a requirement.  While this specification requires that a single cookie- string be produced, some user agents may split that string across multiple cookie header fields.  For examples, see Section 8.2.3 of RFC9113 and Section 4.2.1 of RFC9114. </ins> 5.8.2. The user agent MAY implement "non-HTTP" APIs that can be used to

Related discussion:
text: Adds suggestions for how servers could fulfill the requirement Adds suggestion that servers be mindful of the number and size of the cookies they set to avoid hitting their own header length limits. Also mention that UA should consider splitting longer fields.
If that's the case, I'd recommend punting on getting this in 6265bis - which has had a goal of documenting reality.
It is not unusual for servers to reject HTTP requests that contain individual headers longer than a certain limit. If a client sends a header longer than around 8-9K bytes, the risk is quite large that it will get a 40x response back which effectively blocks the client from continuing what it is set out to do. Because of the rather complicated results of such a "too long" cookie header, I think it could be worth mentioning this in the spec. For newcomers in cookie land, this is perhaps not completely obvious. The spec currently mentions size-limits per cookie, but a server can easily send a few large cookies and have the combined size of them outgrow 8K. I would perhaps suggest wording that says a client SHOULD keep its lines shorter than NNN bytes and servers SHOULD accept cookie lines up to at least NNN bytes. (in curl we have the limit set to 8190 bytes) HTTP related specs rarely speak of this kind of size limits, but I know my implementation could have avoided some issues if this real-world limit had been mentioned.
Seems like a worthwhile warning to me.
RFC 6265 had a requirement that a client MUST generate a single cookie header. HTTP/2 and HTTP/3 allow "cookie crumbling" that permits multiple Cookie headers. 6265bis says in URL What is tolerance really? Why are we stating MUST requirement that are immediately invalidated by two of the versions of HTTP in wide usage? Section 5 is huge, what requirement is the text in section 4.2 forward referencing to? I think there's some room for improvement in this area. An HTTP/2 or HTTP/3 is being instructed as a MUST requirement in the relevant RFCs to combine multiple cookie headers into one e.g. URL but if the server MUST be tolerant to multiple Cookies, maybe we can relax the HTTP/2 or HTTP/3 requirements?
This was the output of the discussion in URL
Thanks Mike, I missed that discussion first time around.
Code change:
HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". <ins> Note: Previous versions of this specification required that only one Cookie header field be sent in requests.  This is no longer a requirement.  While this specification requires that a single cookie- string be produced, some user agents may split that string across multiple cookie header fields.  For examples, see Section 8.2.3 of RFC9113 and Section 4.2.1 of RFC9114. </ins> 5.8.2. The user agent MAY implement "non-HTTP" APIs that can be used to

Related discussion:
text: My question comes about because of some HTTP/2 code I looked at that simply implements HTTP/2 and so combines the multiple fields back into one. But as NAME and NAME alluded to their comments on , the splitting could be done for some reason thst isn't purely about H2 or H3 compression optimization. It seems there are actually use cases where keeping the split is useful, and not just in a private deployment. Of course relaxing things more might have unintended consequences. I find the current text too terse to be useful. This is a cookie spec, it seems like the right place to ba adding commentary about how to handle cookies across various version and conversions. Especially some anecdotal examples about why some clients actually do it.
Mentioning why a server should be tolerant, and what shape that could take, seems reasonable to me. Especially given how nicely it dovetails with . What forward reference are you referring to? ?
In that mention, I think it's worth including that re-combining the Cookie lines before passing to the next layer is a form of tolerance from the client's perspective.
Some more text sounds good and I'm happy to review. In Section 4.2.1:
Still LGTM, thanks!
Code change:
HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". <ins> Note: Previous versions of this specification required that only one Cookie header field be sent in requests.  This is no longer a requirement.  While this specification requires that a single cookie- string be produced, some user agents may split that string across multiple cookie header fields.  For examples, see Section 8.2.3 of RFC9113 and Section 4.2.1 of RFC9114. </ins> 5.8.2. The user agent MAY implement "non-HTTP" APIs that can be used to

Related discussion:
text: Summarizes all the major changes from 6265bis, replacing the existing draft-by-draft change log.
While there are still a couple open issues that may/may not change this PR, I'd still appreciate an initial look. Thanks!
NAME This is ready for review, I don't believe the pending PR needs to be added to this changelog
Looks generally reasonable to me. Maybe drop the IANA changes summary (too detailed), and try to lead with the important changes (e.g., drop the errata down to last)?
It'd be nice if there were an appendix summarising the changes. We do this for most updates.
Sorry for being a bit dense but what is URL in comparison to that? :)
What's needed is a summary of changes from 6265, not for draft-by-draft. And that needs to stay in the spec upon publication.
NAME I see, thanks!
Is there a rule of thumb for which changes should be included? "Major" changes? Any normative changes? Something in between? Also, do you know of any existing RFCs that are a good example?
Major changes definitely, and any significant normative changes. See eg URL
Catching up on things after being out sick for a ~week. This change LGTM. I think the level of detail is appropriate, and I didn't see anything in the line-by-line changelog that jumped out at me as being big enough to consider missing.
Code change:
An example is <del> A sender MUST NOT send a Content-Length header field in any message that contains a header field. </del> A user agent SHOULD send a Content-Length in a request message when no

Related discussion:
text: Good point.
I guess all the options are ugly. Should we leave the text wehre ut was and just apply the proposed change in URL ?
Does better belong in -messaging?
Into 6.2?
Seems like the best place, yeah.
NAME : URL
But I don't know what this accomplishes given the paragraph after this one also refers to Transfer-Encoding.This makes sense on its own (with Martin's adjustment). Still not thrilled about having transfer-codings in semantics.Thanks. Fairly simple fix here. I've suggested a tweak for Roy's concern (which I can't make a suggestion before because of GitHub limitations.
Code change:
The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below: <ins> The applicaiton SHOULD use a relevant status code in SUBSCRIBE_DONE, as defined below: </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE

Related discussion:
text: Into SUBSCRIBEDONE. I didn't remove the SUBSCRIBEERROR message in favor of SUBSCRIBE_CLOSED as NAME suggested in this PR. Addresses some comments in , but possibly not all
So my notes from this discussion. CLOSE is confusing with QUIC layer. People seemed to prefer UNSUBSCRIBE over SUBSCRIBE_CLOSE. I love the move aware from RST and FIN as naming.
Propose names from my understanding of discussion call Announce (send by publisher) , AnnouceOK, AnnouceError UnAnnounce (send by publisher) UnAnnounceOK, UnAnnounceError AnnouceEnd ( sent by thing that received Annouce) , AnnouceEndOK, AnnouceEndOK Subscribe (send by subscriber) , SubscribeOK, SubscribeError UnSubscribe (send by subscriber) , SubscribeOK, SubscribeError SubscribeEnd (send by thing that received subscriber), SubscribeOK, SubscribeError Mostly trying to get rid of FIN / RST and have different names for the messages that flow in opposite directions.
I don't like the name of the different messages used to terminate. I'd rather have one message that transitions to the terminal state, with an optional error code and final group/object. IMO the subscription flow: And the ANNOUNCE flow mirrors: The brackets mean a message is optional. The sender is responsible for creating and the receiver is responsible for closing, possibly at the bequest of the sender (like QUIC's STOP_SENDING).
has been merged, adding yet another term (CANCEL), but I figured we'd clean that up with this issue.
Since we are bikeshedding, I prefer ANNOUNCE_RESCIND instead of CANCEL, since an announce is more of a declarative statement than an active request from the sender.
Heh and UNANNOUNCE and UNSUBSCRIBE stick out because they don't share the same prefix.
I like the names being proposed as they help make make is easier to understand. I do want to separate out one issue. The STOP / CLOSE type thing happens way after the initial SUBSCRIBE thus it can end up in a situation where auth has expired or something else has gone wrong this I like the current design that allows an OK or ERROR to be returned for those. I think it is also key for sender of the things stoping the subscribe to know that the other side has acted on that so we need the OK.
Code change:
The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below: <ins> The applicaiton SHOULD use a relevant status code in SUBSCRIBE_DONE, as defined below: </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE

Related discussion:
text: I'm leaning towards CLOSED instead of CLOSE because CLOSE implies its a requested action, so to me SUBSCRIBE_CLOSE sounds like something the subscriber would send, not the publisher. For a similar reason, I like CANCEL slightly better than STOP, but both work. UNANNOUNCE and UNSUBSCRIBE are good words, but I think it's better to follow a pattern in this case and I like NAME sequence of messages.
NAME CANCEL and CLOSED are slightly better, sure. NAME there MUST still be an OK before objects can be sent. That way the receiver can tell upon receipt of the CLOSED if the subscription was ever active.
So to add an OK, we need to add another state. The question for me is what is the use case where we need to deliver that information in the end of the subscribe.
This discusion is probably easier looking at state machine diagrams
Sections 6.8 and 6.9 strongly imply that SUBSCRIBEFIN/RST are sent at the true end of the track. So are they not sent at the conclusion of a SUBSCRIBE that does not cover the end of the track? For example, if the last object of a track is (10, 12), and there's one subscribe for (4,0) to (5, 100) Is there a SUBSCRIBEFIN? If not, how does the subscriber know that in fact (5, 60) is the last object in that subscription? If so, does Final Group and Final Object refer to the last object in the subscription?
Individual Comment: Putting my HTTP hat on for a second, when you ask for something with unknown length, you infer from a graceful termination that the last thing you got was the true end of that resource. If you send a range request, the graceful termination at the end does not convey that the last thing was the true end. Once the object expires, you can issue another request to the same name and potentially get a totally different thing. Does this model work for moq, or do we need something different?
There are three different things you might want to communicate to a receiver at the end of the subscribe: 1) You got all of the objects in the range; 2) You got almost all of the objects, but some were dropped for latency/bandwidth reasons 3) The track was truncated for some reason and possibly, 4?
Code change:
The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below: <ins> The applicaiton SHOULD use a relevant status code in SUBSCRIBE_DONE, as defined below: </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE

Related discussion:
text: 4) You got everything I have but i'm not sure if that's everything
is somewhat relevant to this issue.
As mentioned in , there are 3 different ways for a publisher to close a subscriber, each with minor differences. : I never sent you an object. : There are no more objects to send after group/object X/Y. : There are more objects after group/object X/Y... but I won't send them. A few things: I think it should be renamed since it's not the only ERROR message. Maybe ? The only difference is that one has an error code. Otherwise they both include a final group/object and it's up to the application/library to decide if they wait for the final object(s). I'd like to only implement this once but right now I have to copy/paste any code to handle these almost identical messages. What if we merged them and use error code 0 to signal a FIN. The reason phrase should be removed as part of . There really needs to be a state machine like with this many ways to terminate a subscription. I think these are all protocol violations: then then then My interpretation of the draft is that a followed by a is invalid, which is not obvious and unlike QUIC. I don't think so. The library/relay behavior doesn't change based on . The only thing that miiiight differentiate between the two is the application, which can use errors codes for this purpose. At the very least I would merge these two messages. But I would also like to explore a single way for the publisher to close a subscription. The application can signal the nuanced differences between errors (ex. error code 404 vs 410). The library/relay doesn't care, it just forwards the error code.
Individual Comment: The inspiration for FIN vs RST in moq came from HTTP caching. If a resource has no content-length, and the caching proxy has received N bytes, does it have the entire resource, or does it need to refetch the tail? If that response was terminated with a FIN (H2 or H3), then it has the whole resource. If it was terminated by a RST, it can't assume that it does. So the value I see in these two messages is for a moq relay is similar.
Code change:
The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below: <ins> The applicaiton SHOULD use a relevant status code in SUBSCRIBE_DONE, as defined below: </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE

Related discussion:
text: A client connected to the relay and subscribed to a track, which fowarded the subscribe to a publisher. The track was published to the relay and ended with a FIN. Another client subscribes to this track from the beginning (Absolute/0,0) and no end. Does the relay need to resubscribe upstream? Now suppose that the connection from the publisher to the relay closed abruptly, or the track was terminated with SUBSCRIBE_RST. This is a signal to the relay that it's worth another subscribe to find out where the end of the track is. I can live if we consolidate the framing to a single message, and define a special error code to mean FIN, but I do think the transport needs to see the difference.
I like it. I would also like to merge ERROR with CLOSED, but we'll chat about that.
Code change:
to distinguish them from decimal literals. <ins> This specification describes binary formats using the convention described in QUIC. </ins> The following terms are used: Finally, the terms "gateway", "intermediary", "proxy", and "tunnel"

Related discussion:
text: I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.
Code change:
The encoding and decoding of header fields relies on some components and concepts: <del> A name-value pair.  Both name and value are sequences of octets. </del> <ins> A name-value pair.  Both the name and value are treated as opaque sequences of octets. </ins> The header table (see header.table) is a component used to <del> associate stored header fields to index values.  The data stored in this table is in first-in, first-out order. </del> <ins> associate stored header fields to index values. </ins> The static table (see static.table) is a component used to associate static header fields to index values.  This data is

Related discussion:
text: Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.