jiebi/CodeConvo huggingface dataset:
A dynamic table entry that has not been acknowledged by the decoder must not be evicted by the encoder, even if there has never been any references to it. This is already alluded to in the current spec at URL by the phrase "acknowledged by the decoder", but since "acknowledged" is used interchangeably for acknowledging the insertion instruction and acknowledging references, a reader could understand this to mean "all references acknowledged". In addition, at three other places eviction of entries with unacknowledged references are banned, with unambigously no ban on eviction of unacknowledged entries with no references. I argue that more explicit language would be beneficial. This issue has already been discussed at URL and below. Note that avoiding this kind of corruption could also be achieved by banning an encoder from inserting entries that it does not immediately reference, but this is probably way too restrictive. For example, an encoder might wish to achieve best latency and speculatively improve future compression ratio at the expense of potentially wasting current bandwidth by encoding header fields as literals while inserting them at the same time for potiential future use. This is already alluded to in the spec at multiple places. Below is a specific scenario when this issue might cause corruption: Suppose MaxEntries is 5. Suppose that there is a fresh connection, with an empty dynamic table, and there is a header list to be sent that has two header fields which fit in the dynamic table together. Suppose one encoder implementation inserts these two header fields into the dynamic table, and encodes the header list using two Indexed Header Field instructions, referring to absolute indices 1 and 2. This header block will have an abstract Largest Reference value of 2, which is encoded as 3 on the wire. A spec compliant decoder should have no difficultly correctly decoding this header block. Suppose another encoder implementation starts by adding 10 unique entries, all different from the two header fields in the header list to be sent, to the dynamic table, but does not emit references to any of them. Of course in the end only the last couple will stay in the dynamic table, the rest will be evicted. This can be considered spec compliant depending on how one interprets the spec, see above.
Suppose that after this, this encoder implementation encodes our header list by inserting both header fields into the dynamic table, with absolute indices 11 and 12, and using two Indexed Header Field instructions on the request stream. The abstract Largest Reference value is 12, which is encoded as 3 on the wire since 2 * MaxEntries == 10. Now suppose that out of the 12 instructions on the encoder stream, only the first two arrive before all the request stream data are received. The remaining 10 instructions on the encoder stream are delayed on the wire. Now a spec compliant decoder sees the same header block on the request stream, bit by bit, as above, and two insertions on the encoder stream. It will emit dynamic table entires 1 and 2, which are different from the encoded header list.
You should really create a new issue for these things. Because this comment relates only to the issue, not the proposed fix. I haven't read the proposed changes, though I will if you think that there is a fix in there that is worth keeping after this. Anyhow, the example is invalid here: Because: And you can only ever fit 5 entries in that table.
That's exactly the issue: "it has first been acknowledged by the decoder" is ambigous. "Acknowledged" is being used throughout the text with two different meanings, most often to refer to references, not insertions. The ban on evicting an entry the insertion of which has not been acknowledged, that you are quoting, only occurs once out of four different locations talking about when an entry can be evicted. The other three places clearly only ban evicting an entry with unacknowledged references (note the use of the same word), giving the impression that acknowledgement of the insertion is not necessary before eviction. Since the design is correct if you read it right, but wording is not as clear as I think it should be, I consider this issue editorial. The change I propose in this PR is meant to be an improvement on clarity.
OK, having read the changes, I agree with them. They consolidate the fix by creating two conditions that cause an entry to be "blocking".
Rebased on . Please let me know if anybody can come up with a term better than "blocking" which is confusing given that streams can be "blocked".
In places, the current draft doesn't make a clear distinction between rejection and decryption failure. In particular "cannot decrypt" can be interpreted either: "the client-facing server doesn't recognize the configuration specified by the client"; or "the client-facing server recognizes the configuration but decryption fails". This change resolves this ambiguity. Addresses issue .
Two sections suggest to ignore the extension on decryption failure, but one suggests to send an alert. What should happen? Ignoring the extension on unrecognized failures sounds reasonable in order to "not stick out". However, it is not entirely unambiguous what to do if a valid ECHConfig is found but decryption fails. says: says: says:
I think the first two statements apply when the config_digest doesn't correspond to a known ECHConfig (i.e., "I can't decrypt this"); the last is when the ECHConfig is known, but decryption fails ("I should be able to decrypt this, but the ciphertext is invalid"). The text could be a lot clearer here.
NAME Yes, your interpretation is correct. I think this is the result of a number of uncoordinated changes.
Closing as resolved.
attributes. As far as I can tell this can happen: On re-offers On any answer because nothing requires the offerer to generate bundle tags in the same order as m= lines (even though the data channel m= line is last) See: URL
NAME PTAL
Say you have a session where only a data channel is created. SDP looks like [session boilerplate] a=group:BUNDLE d1 m=X application UDP/DTLS/SCTP webrtc-datachannel a=mid:d1 ... Now, a media m= section is added (i.e. after first o/a). SDP becomes: [session boilerplate] a=group:BUNDLE d1 a1 m=X application UDP/DTLS/SCTP webrtc-datachannel a=mid:d1 a=ice-ufrag:ABCD ... m=X audio UDP/TLS/RTP/SAVPF 0 a=mid:a1 [no ice-ufrag or TRANSPORT attrs, since bundled] Now, where does a=rtcp-mux go? It can't go into because of the language that states Thoughts on how to resolve?
Could generating a session description be split into two parts? First, generate media-level attributes for each "m=" section, then transport-level attributes for the BUNDLE group and each non-bundled "m=" section.
That would be my preference, i.e., jam it into the BUNDLE group m= section, regardless of media type, as that's conceptually simplest, and easily handled here in JSEP. Either way, I suspect this will require changes upstream in the bundle spec.
So ... is it really not allowed in the d1 section. Unknown attributes are allowed in the d1 section, they are just ignored if they have no meaning for the data channel. Agree this sounds like something that will hit bundle.
Couldn't you do a=group:BUNDLE a1 d1 I would have thought this was prohibited, but is it really? URL
I think that's legal, but that approach doesn't work in the general case, where "m=" section A has TRANSPORT attributes that only it uses, and section B has TRANSPORT attributes that only it uses. BUNDLE just needs to allow an "m=" section to contain attributes that it normally wouldn't contain if it wasn't bundled. (If this isn't already allowed).
NAME any action needed here?
I think what we want in this scenario is to put "a=rtcp-mux" and "a=rtcp-rsize" in the data channel section. The simplest way would be to say: Which I guess could only happen in subsequent offers.
Let's go with what NAME suggests, although this makes it a bundle problem.
What would you say is needed on the BUNDLE side? Just clarification that the offerer BUNDLE-tag m= section should contain the union of all TRANSPORT and IDENTICAL attributes used by the BUNDLE group?
talked to chairs and advice from chairs on this and similar things that depend on mmusic outcomes. We put in JSEP now what our best guess is of how mmusic will end up and publish JSEP. At the same time we log a bug to check if we need to make any changes to line up with what mmusic decides. We can take changes to line up with mmusic as Last Call comments later on.
+1 with Taylor proposal to put RTP related things in data m= section if it is first and good with making this be bundles problem
NAME NAME I assume that you think that on initial offers this cannot happen because data comes last?
NAME Right. I can't think of a scenario where it wouldn't go last in an initial offer.
Agreed.
Oh, except that you aren't required to make the bundle group in order So you can have
I don't think the question whether you are allowed or not to place an RTP attribute in a non-RTP m= section is a pure BUNDLE issue. One needs to check what the specs defining those attributes say.
every SDP spec has to accept (and ignore) lines it does not understand ...
I looked into the a=rtcp-mux and a=rtcp-rsize specs, and I didn't see anything that prohibited their inclusion into a non-media section. Generally, I think BUNDLE can define the rules for this sort of thing, without fear that it will somehow contradict some other spec.
NAME NAME You may want to chime in on the current MMUSIC thread. I agree with you, but it seems to be going in the direction of "you can't do this".

I looked into the a=rtcp-mux and a=rtcp-rsize specs, and I didn't see anything that prohibited their >inclusion into a non-media section.
Based on The delegation certificate MAY have the DelegationUsage extension marked critical. This also adds a "strict" flag to the extension that, if set, requires the server to offer a DC. An alternative that was discussed is to add an optional TLS-feature extension (per RFC 7633) that would provide a "must-use-DC" feature, analogous to "must-staple-OCSP". Howver, it's possible for a certificate with such an extension to be used in a handshake without DCs if the client doesn't indicate support for DCs.
This seems to be a layer of indirection that doesn't add any value to implementation.
The Credentials section claims there is an epoch id field in key packages. I don't think that actually exists. My apologies if this is a duplicate issue.
Addressed in but may need to be pulled out depending on the fate of that PR
contains all of the Proposals that were previously sent within the same epoch. This seems unnecessary, since all members should have them anyway. The list of in the actual message should be enough for members to parse and validate a message. We should discuss if we can de-duplicate this, since the list of Proposals might be quite long.
The current definition of is as follows; Maybe this issue is obsolete?
Seems it is now obsolete indeed.
I don't have a strong opinion on this question, but this change seems sensible to me. The use of LeafNodeRef requires either (a) a linear scan through the tree, which is time-expensive in large trees, or (b) keeping an index that maps LeafNodeRef values to indices, which is storage-intensive in large trees. IIRC, the change to LeafNodeRef was made in the context of NAME work to make the tree description less tied to the array representation. In general, that is the right thing to do, and it's good that we did it. But we still have leaf indices anyway, for . Since we still have the concept, we might as well use it where it makes sense. And it certainly seems to me like and make sense, since they are internal to the protocol. In case folks are worried about the application-facing API -- MLS stacks can certainly be more intelligent, e.g., exposing or or . But they can do that regardless of this PR.
Here's a first attempt to combine terminology sections, and trust model. Includes new terms Endorser and Appraisal Policy per recent discussion. Signed-off-by: Dave Thaler
Done
Done. (But if you have feedback on a sentence like this in the future, please attach the comment directly to the code line under the "Files changed" tab, to make it easy to find which phrase you're referring to.)
Done
Updated. How about now?
I would like to discuss the possibility of combining the terms "Endorsement" and "Attestation Result". Just like we have an Appraisal Policy for a verifier and an Appraisal Policy for a relying party, some might view an Attestation Result as an Endorsement for use by the relying party. I'm ok either way, but wanted to discuss this in our next call to see if others think it would help or confuse things.
I still believe my original definition of Attestation is good, I haven't seen any comments here about what the problem was. For comparison, URL says it's "The process of validating the integrity of a computing device such as a server needed for trusted computing.". I'm also ok with that definition.
I’m OK with that wording for introducing the concept. It may break down if the terminology for ‘device’ and ‘trusted computing’ become overly specified / specific.
The word 'health' is generally being used where other words such as 'trustworthiness', or 'state' could be used. I'm concerned that 'health' might not easily be synonymous with 'trust'. It also seems to bias the architecture toward NEA (RFC5209) which IMO does not define attestation.
Use parentheses as an indication that something is a function. Also, don't confuse the reader by alluding to potential future alternatives to value(). Reviewers: is this an improvement? It's a draft PR for now until we decide the change is worthwhile.
I think we'll need to explain the () notation, which should be familiar to C programmers but not necessarily to people who grew up on other languages. I also think we have a few more examples that point to hypothetical functions, such as , , .
I don't think there's a great point at which to explain that notation and, based on your observation, I'm going off the idea.
NAME Let's see how pans out before taking the current PR any further. Once I remove the function parentheses, the two PRs are changing the same text.
would be the place.
NAME As you suggested, I introduced this in 1.1, but near the start since it's notation rather than terminology. I did a regexp search to find and fix the remaining examples (your list was complete). In doing so, I found the strange markup and removed the backticks since there was no good reason for them.
We could do the fun() explanation and completeness search in a separate PR.
In Section 2: When running over HTTP/1, requests are strictly serialized in the connection, therefore the first layer of demultiplexing is not needed. Is there any actual possibility to run more than a single request with HTTP datagram support over an transport connection? When one runs an HTTP request that enables datagram I don't see how it would be possible to close that request in any other way than closing the underlying transport connection. Or are there a way that I am missing that would enable one to close this request, and then issue another pipelined HTTP request that also uses HTTP datagrams? Is there a need to clarify this, or make it clear that only a single HTTP request with datagram can be sent?
In section 2, we've yet to mention anything about how the rest of the spec operates. So the comment in isolation is correct when talking about the general concept of multiplexin. I see your point but I'm not sure saying anything more here will help. Section 4.1 provides the details that implementers need to do the right thing.
Okay, but lets include Section 4.1 also into this. I assume you are referring to this sentence: In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section, or the 2xx (Successful) response header section. But, per URL this body length length rules will be those that could govern a closure of a HTTP request enabling datagram. Would it be realistic to actually make it clear that if one enable HTTP Datagram transport close is the only, way or is that just creating additional rules making implementation even more? Otherwise do we need additional analysis if there are possibility that any of these rules could actually result in a closing a HTTP request?
There is no HTTP content on upgrade requests, we should link to the definition of Upgrade URL and make things slightly more clear in Section 4.1.
Ok, I guess it becomes a question of which method for enabling datagram one uses, if this is an upgrade or a new method. And I would note that Connect method appears to have some interesting exceptions compared to other methods. Which I think makes this into a requirement on the using method/upgrade that uses HTTP datagrams to actually specify this aspect.
I've written up to clarify that pipelining is not supported.
Added text to address issue
There is a potential issue for credential renewal. On the credential owners side there is a risk that if the owner entirely depends upon the delegated credential lifetime to renew it could miss the fact that the underlying certificate has already expired will cause clients to fail validation. This can be addressed by adding the following to section 3: "Peers MUST NOT issue credentials with a validity period longer than the maximum validity period or extend beyond the validity period of the X.509 certificate" Or there could be an addition to the operational section that talks about renewal. "5.2 Credential Renewal Credentials must be renewed before they expire and before the issuing X.509 certificate expires. "
addressed by pull request
Lots of niggly details re blank space. Style consistency, some missing places (assuming we stick with the liberal approach). Allowing "in" before or after a newline or tab. Adding some legend to the only remaining table with XPath content in the main document.
[ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be (Do not use the term "whitespace" any more.) Task "T1" in the document URL
and
From the document: (whitespace is now generally called blank space, but that doesn't change the work to be done.)
and
How much do we want to reference XPath within the spec? I understand that XPath is the inspiration (and in the tagline that NAME used in his blog post: "XPath for JSON"), but I wonder if much of this can be left out of the spec. The argument for this is that we're defining JSONPath. It shouldn't assume any understanding of XPath or any other technology. It's not the job of the specification to convince readers to use it. It's the job of the specification to define the technology. I'm perfectly happy moving this into an external "Understanding JSONPath" website at some point.
I seem to remember that last time we discussed this we agreed to move the introductory comparison with XPath to an appendix, with the possible exception of the overview table (but that could be duplicated).
The XPath inclusion was moved into an appendix.
Do we allow spaces (outside of string literals)? If so, where is whitespace allowed? I think whitespace in query expressions should be allowed. This would fall in to the context of the . Maybe inside the union/ selector: Are there any other places where whitespace could be considered useful?
It may be convenient to allow spaces between matchers - to allow well-readable multi-line queries for complex cases.
Looks like the allows whitespace internally, so that (with leading and trailing whitespace) is valid.
Closed in and
What was the resolution here? Where did we end up allowing whitespace?
Several small updates: Issue 15: local media state, local resources correct, removed comment. - Issue 16: updated wording to use 'calling this method', removed comments, - Issue 17: changed stopTransceiver to stop, removed comments, - Issue 18: changed 'directional attribute' to 'direction attribute', removed comments,
LGTM once lands
18) [rfced] Section 4.2.5: We see "direction attribute" but not "directional attribute" in RFC 3264. Will this text be clear to readers? (We ask because we also see "A direction attribute, determined by applying the rules regarding the offered direction specified in [RFC3264], Section 6.1" in Section 5.3.1 of this document.) Original: More specifically, it indicates the [RFC3264] directional attribute of the associated m= section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer.
This should indeed be , as that's the terminology used by 3264.
NAME please close this issue once you consider it resolved.
17) [rfced] Section 4.2.2: Will "stopTransceiver" be clear to readers? We could not find this string elsewhere in this document, anywhere else in this cluster of documents, in any published RFC, or in google searches. Original: The stopped property indicates whether the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section.
This should be , rather than .
NAME please close this issue once you consider it resolved.
16) [rfced] Section 4.1.16: Should "The effects of this method call" be "The effects of calling this method," and should "This call" be "Calling this method"? Original: The effects of this method call depend on when it is invoked, and differ depending on which specific parameters are changed: ... This call may result in a change to the state of the ICE Agent.
SGTM
NAME please close this issue once you consider it resolved.
15) [rfced] Section 4.1.10: Please confirm that "local media state" and "local resources" (as opposed to remote) are correct in the context of setRemoteDescription.
(We ask because we see identical wording in Section 4.1.9 ("setLocalDescription").) Original: This API changes the local media state; among other things, it sets up local resources for sending and encoding media.
yes, this is correct
NAME please close this issue once you consider it resolved.
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right
Thanks for these fixes! I did a bit of reworking of the abstract, but it keeps the main part of the changes you made.
Regarding the sentence you removed, that was an adaption of an existing sentence, which I believe aimed to mention the words implementation and API to implicitly refere to the other docs (which was probably too subtle for anybody to notice anyway). However, the other change I made to that sentence was to mention one of the benefits / deployment incentives for taps (dynamic protocol and path selection). I wasn't sure about the wording here, but I think it would be good to (re-)add a sentence to the abstract saying why taps is so great and that everybody should deploy it.
Yes, the original second sentence was aimed at mentioning that there were two other documents, API and Implementation, that would be based on this one. I liked how in your revision, it did try to make things clearer than just saying "flexible transport networking services", but I felt that the specific example of dynamic path and protocol selection was a bit too specific for that one line. (I was chatting with NAME about this as I was editing, btw). My thought was that the list of features that you added in right after that, which go through the top-level bullet points of the advantages, do a more comprehensive job of summarizing the benefit.