jiebi/CodeConvo huggingface dataset:
Code change:
Abstract This specification describes data formats as well as validation and <del> processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- selective-disclosure-jwt format.  It can be used when there are no selective disclosable claims, too. </ins> 1.

Related discussion:
text: a bit of the context... this trailing ~ is the result of the decision being taken in SD-JWT spec to better align the issuance and presentation formats, (URL does it, and it has not been merged yet). One option is to keep issuance and presentation formats separate in SD-JWT (as-is) so that there is no ~ when (SD-)JWT VC is issued. but that is not that clean from a pure SD-JWT processing perspective is I think the opinion of its authors (NAME NAME so the question is really what to do with a trailing ~ when there is no SD in SD-JWT based VC.
should be good to merge once NAME takes a look and approves
I'm ok with this direction. I personally don't like the trailing tilde but we can fix that in another PR. I'll open an issue in the repository.
Merging this PR since a lot of approvals and no objections.
approving but will create an issue to address trailing tilde.I approve this approach over as, the specification is much cleaner I expect implementations to be much cleaner I don't see confusion with trailing tilde, because typ is not jwt but sd-jwt most interop profiles will require SD support anywayI prefer URL since I find its description of what we're achieving more natural / less surprising. But I can live with this description as well, provided the distracting "with JSON Claims" language is removed.
Code change:
3.4.5. <ins> An attacker obtains the contact information for a user and contacts them, pretending to be a representative of the user's financial institution.  The attacker informs the user that there were a number of fraudulent transactions against their account and asks them to review these transactions by approving or rejecting them.  The attacker then triggers a sequence of transactions.  The user receives an authorization request for each transaction and declines them as they do not recognize them.  The attacker then informs the user that they need to close the users account and transfer all the funds to a new account to prevent further fraudulent transactions.  The user receives another authorization request which they approve, or provide additional authorization information to the attacker which enables the attacker to complete their attack and defraud the user. 3.4.6. </ins> An attacker creates a message to all employees of a company, claiming to be from a trusted technology provider investigating a suspected security breach.  They ask employees to send them the QR code

Related discussion:
text: See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).
Code change:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <del> 6.12. </del> <ins> 6.14. </ins> The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control

Related discussion:
text: Delayed LGTM.
Section 5.1 of the draft says: For the second case above, I think it would be useful to have an explicit signal from the publisher to signal the end of the track. For the third case, the text seems to hint (via a section reference) that if the subscription abruptly terminates with an error, the publisher can send SUBSCRIBE ERROR, but that section says: The draft should clarify if this is allowed following a SUBSCRIBE OK. Also +1 to adding UNSUBSCRIBE ().
+1 we should allow sending a SUBSCRIBE ERROR after a SUBSCRIBE OK.
I was assuming that the catalog change would be the way a track end was indicated then the client would unsubscribe.
As an individual: This seems like a bit of a subtle signal and something more explicit using the Track ID would be preferable for me.
I tend to incline towards Catalog indicating the status the more i think of it. Catalog is source of truth for tracks. Having a catalog update that indicates the following Full Track Name lastobjectid field Also if the catalog is ending, since the producer is going away, then include another optional field finished or something These would be sufficient and a clear way to identify the status end to end.
I think putting the FIN group/sequence in the catalog is clean. It does prohibit relays from cleanly terminating a broadcast early or rewriting group/object sequences, but I think that's fine? However, the wrinkle is that a sender MAY choose to not transmit a group/object. While I don't think this is explicitly stated in the draft, it's a requirement given that relays can only cache data for a finite amount of time. The viewer could get stuck waiting for the FIN group/sequence as signaled in the catalog, even though it is not forthcoming as the relay did not receive the object or already evicted it from the cache.
As an individual: Having an explicit signal outside the catalog will make it easier for relays to clean up track related state. If a publisher is done with a track, they can update the catalog, but it will need to propagate to all subscribers, who in turn need to issue an unsubscribe. Only when all of them unsubscribe (which we still need) can a relay discard the entry in the forwarding table. If the publisher also sends an explicit signal closing off the track, the relay can immediately clean up the state.
We need few things.
Code change:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <del> 6.12. </del> <ins> 6.14. </ins> The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control

Related discussion:
text: Cease the announcement This is an explicit signal from the publisher that it is no longer interested in sending media for the announced tracks. This is sent to the relay to trigger subscription cancellation downstream and clean up local relay state. Terminate the Subscription On subscribe end signal, each receiving entity will forward downstream and clean up local state. If it is the consumer, it stop media pipeline and so on. Unsubscribe For subscribers to explicitly indicate that they are no longer interested in a given track , they will send I am happy to write up a small PR as proposal if we think the general direction is fine.
What is the difference between Cancel the subscription and Unsubscribe?
Unsubscribe is an explicit action from the subscriber and Cancel is the signal from the publisher. May be we should call it ` instead ? I see cancel can be misleading
Got it. Terminate is better than Cancel.
We already have for the publisher to immediately terminate a subscription with a code/reason, so we could reuse that. However, the problem is when the termination occurs. The end of a broadcast would look like: There's a race, as the can arrive before the last objects due to retransmits or congestion control, severing the subscription early. Ideally we wait for all outstanding objects to get delivered and then terminate the subscription. In QUIC terminology, we need a in addition to our existing . The difficult part is determining which objects are still outstanding.
Do we want to distinguish a normal end of subscription (due to EOF), and an unexpected end (due to, e.g., a downstream server crashing)? We do that normally in QUIC (fin vs reset), so it might make sense to do that here.
Image the case where we have A sending to R sending to B. B subscribes to R. A sends ANNOUNCE to R. R subscribes to A. At this point media is flowing from A to R to B. A temporary looses WIFI connectivity and reconnects over 5G with new IP. A sends an ANNOUNCE to R, R subscribes to the new A and perhaps tries to send an error to original ANNOUNCE and end subscribe but A will not get that as that QUIC connection is gone.
Code change:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <del> 6.12. </del> <ins> 6.14. </ins> The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control

Related discussion:
text: Once again data is flowing from A to R to B. I think it would be bad if the new ANNOUNCE, or an error on the QUIC connection from A to R caused a termination or error of the subscribe between B and R. I'm think it is better for B to unsubscribe if it is not receiving the media it wold expect.
Having explicit messages reflecting the actions would be my inclination as well. I thought it might be beneficial to explain the role of the above proposed messages with few flow diagrams Here is the happy path flow (it ignores Subscribe_OK and response flows to keep the flow focussed)
Summary thoughts: Want to support disconnection without propagation to all subscribers (ie: If there were two publishers) Need a way to cleanly unsubscribe from a track (UNSUBSCRIBE) - Like STOPSENDING? Need a way to indicate that a relay is no longer the place to subscribe to for a track (ie: UNANNOUNCE) But UNANNOUNCE does not indicate an unsubscription. Need a way to indicate the track is FIN'd and ending, could use the catalog or put in the protocol (or both) Likely want a way to drain a relay, such as an HTTP GOAWAY style functionality. (Could be SUBSCRIBETERMINATE) Timeouts do need to be handled, even if they're not the ideal/clean case. Want to know whether the relay wants to stop publishing or the origin did, so a client can decide whether to re-sub. NOTE: Objects can be dropped, hard to know if they'll ever arrive. Cullen will summarize a proposal. Note that the relay doesn't really need to know about tracks or what its subscribing to. An open issue is how to do FIN, whether it as part of Objects, only the catalog, a separate message, etc.
Rough notes on proposal in the call: The catalog updates and says what the last message in a track is. Catalogs are a way that endpoints can say there will never be more on a track. The annouce has an equivalent un-Annouce message. It changes routing of future subscribes but does not change state of existing subscribes. The entity that send an subscribe and send an un-subscribe The entity that receives a subscribe can send a go-away which will let the entity that sent the subscribe go do something new ( like subscribe to something else ).
Code change:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <del> 6.12. </del> <ins> 6.14. </ins> The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control

Related discussion:
text: We might need to figure out what data goes in the go away to given info that the clients enough info to do the right thing. Timeout can happen, and connections disappearing, and we need to sort out what impact that has but that is not the primary way to cause flow of media to change. Update: Key issue here is when the relays see the go away, do they drop the related forwarding state for the subscription, or do they just forward the update to the subscribers and wait for the subscribers to remove the subscription.
NAME NAME thanks for capturing the notes. I will work on set of small PRs to capture some of the items from the summary.
The point I was trying to clarify on the last call was that catalog already has a mechanism for a publisher to communicate to all subscribers that the track it has advertised as being available is no longer available. A clean FIN if you like. We can, as has been pointed out, create a control message which says the same thing. But then we have a weird asymmetry in which a publisher notifies clients of track availability through a catalog update but then uses control messages to do the reverse. For good design with clean encapsulation, we should seek symmetry in operation. We should either use control messages to advertise the availability/unavailability of tracks , or use catalogs, but not a hybrid of both. In my understanding of moq-transport, control messages have utility that is scoped to the current hop. They negotiate the format in which data will be exchanged on that hop and issue commands to subscribe/unsubscribe/announce etc. Those commands have no applicability to any other hops on the distribution chain. A catalog however is a contract between a publishers and all subscribers. Unlike control messages, it holds data that is not interpreted hop-by-hop and is intended for targets that can be many hops away. I think relays should be as simple as possible. In my conception, they should not understand whether tracks are being published or not. Their job is to move objects. Their view of the world is around objects and they do not need to understand what tracks are. While of course we can build all sorts of track intelligence in to relays, I think if we can build a base protocol which is agnostic to tracks, then it will be scalable and robust, and cleverness with tracks can evolve in the streaming formats without affecting deployed networks of relays.
Code change:
4.1.1.1. Transparency Services MUST, at a minimum, perform the following <del> checks before registering a Signed Statement: * Authenticate the Issuer of the Signed Statement </del> <ins> checks before registering a Signed Statement: Authenticate the Issuer of the Signed Statement </ins> The Transparency Service MUST authenticate the Issuer of Signed Statements by validating the COSE signature and checking the identity

Related discussion:
text: While working on a unrelated PR, I noticed that lists that do not have a newline between the list and previous paragraph. The end result is in local testing, and presuming upcoming publication to URL, the lists will not render correctly. I added newlines and also change the equivalent Markdown syntax to match preexisting lists from other sections in the draft that have been around longer. Before: ! After: !
LGTM Thanks, NAME
Code change:
scheme, host and, optionally, port number and path components, but no query or fragment components. <del> The following is a non-normative example of the URL of the JWT Issuer Metadata configuration when </del> <ins> 5.1. A JWT Issuer Metadata configuration MUST be queried using an HTTP request at the path defined in jwt-issuer-metadata. The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when </ins> is set to : <del> The following is a non-normative example of the URL of the JWT Issuer Metadata configuration when </del> <ins> If the value contains a path component, any terminating MUST be removed before inserting and the well-known URI suffix between the host component and the path component. The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when </ins> is set to : <del> The JWT Issuer Metadata configuration MUST be a JSON document compliant with this specification and MUST be returned using the </del> <ins> 5.2. A successful response MUST use the and return the JWT Issuer Metadata configuration using the </ins> content type. <ins> An error response uses the applicable HTTP status code value. </ins> This specification defines the following JWT Issuer Metadata <del> parameters: </del> <ins> configuration parameters: </ins> JWT Issuer Metadata MUST include either

Related discussion:
text: The rules for obtaining the issuer metadata needs to be extended to cope with paths as well. I suggest to use the text from URL
The following example is already supported ... NAME is this what you had in mind, or is there anything missing? In that case, we could add an example that makes it more visible that this use case is supported.
URL needs to be URL have a look at URL
Ok, makes sense. Will create a PR to fix that.
Code change:
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section. <del> 6.3. Some network media may provide their own mechanisms for advertising NAT64 service to the stub network.  If such a mechanism is available, stub routers MUST use the mechanism provided by the network medium used on the stub network to advertise NAT64 service.  Otherwise, NAT64 service MUST be advertised using the PREF64 Router Advertisement option RFC8781. 6.4. </del> <ins> 7. </ins> If a stub network is constructed using mesh technology, it may become partitioned.  In such a situation, it may be one stub router is

Related discussion:
text: Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.
Code change:
reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The "standard" status is not suitable for an algorithm that is known to <del> be weak, broken or experimental.  If a registration request attempts </del> <ins> be weak, broken, or experimental.  If a registration request attempts </ins> to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional".

Related discussion:
text: s/ise-case/use case e.g. -> e.g., nit pass
Code change:
H heuristic expiration time <ins> heuristically cacheable </ins> M max-age (cache directive)

Related discussion:
text: For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.
Code change:
A message that is constructed without encoding a known length for each section uses the format shown in format-indeterminate-length: <del> That is, an indeterminate length consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. </del> <ins> That is, an indeterminate-length message consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be

Related discussion:
text: Comment by NAME , Figure 1: , Figure 2: For consistency with the rest of Figure 1, you could add a comma after Content(..) and Chunk (..) : Missing word "message" : s/intermediate/indeterminate
Comment by NAME The document uses "indeterminate length" and "indefinite length" interchangeably. I would suggest either using only one, or adding "indeterminate" when the first "indefinite" appear, i.e. in :
Comment by NAME : Should these be "informational" rather than "information"?
Comment by NAME : Please reference RFC-ietf-httpbis-semantics, or , or the IANA registry: URL after "status code".
Comment by NAME : : I think HTTP/2 should be a normative reference.
Comment by NAME : Might be worth clarifying that this integer value does not include the length bytes. My comment comes from the fact that "field section" is the name of the structure containing the length, so "number of bytes in the field section" could be interpreted to include the length bytes itself.
Comment by NAME : : At this point in the text I thought this was missing the optional Informational response field, but you say explain that several paragraph later. Maybe clarify here that this is for messages that are not responses containing informational status codes, or move those paragraphs closer together?
I think that moving the paragraphs works best here.
Code change:
parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. <ins> 6.1.1.2. The DELIVERY TIMEOUT parameter (key 0x03) MAY appear in a SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message.  It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received.  The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference. If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription.  The publisher SHOULD always specify the value received from an upstream subscription when there is one, and nothing otherwise.  If an earlier Object arrives later than subsequent Objects, relays can consider the receipt time as that of the next later Object, with the assumption that the Object's data was reordered. If neither the subscriber or publisher specify DELIVERY TIMEOUT, Objects are delivered as indicated by their Group Order and Priority. When sent by a subscriber, this parameter is intended to be specific to a subscription, so it SHOULD NOT be forwarded upstream by a relay that intends to serve multiple subscriptions for the same track. Publishers SHOULD consider whether the entire Object is likely to be delivered before sending any data for that Object, taking into account priorities, congestion control, and any other relevant information. </ins> 6.2. The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages

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