jiebi/CodeConvo huggingface dataset:
Most of the text was correct in that we talk about making a request of a resource. Where the text refers to making requests of a server, those usages seem to be correct.
Section 5 details HTTP usage. It seems it's technically correct but the section closes with a sequence of paragraphs that jump back and forth between statements about how an Oblivious Gateway Resource treats requests or responses. Perhaps these could be consolidated to present requests first consistently. I.e. swap the final two paragraphs around
mnot recently made a PR (now merged) that replaced "requests of a server" with "requests to an origin server" and that feels both grammatically and technically more correct. However, there are still few cases peppered through the doc that use "requests of a server". I'd kindly ask the editors to revisit these and consider if they could be made more consistent with the above
When we prohibited the use of application-layer CONNECTION_CLOSE in these packets, we should have updated the text in the description of the packets also.
I think the spec is ambiguous when it says in section 17.2: and: >Handshake packets MAY contain CONNECTIONCLOSE frames. But CONNECTIONCLOSE can mean 0x1c or 0x1d. Are both permitted during the handshake?
NAME In this case, the intent is to allow both. Unless explicitly specified, I would read the text to mean both types of CONNECTION_CLOSE frames.
Okay, if more people think that way, we can close with no action.
So on the surface, there is no inconsistency: the two sections permit CONNECTIONCLOSE. But the question about the different types of CONNECTIONCLOSE is more relevant than NAME response might imply. We currently require that CONNECTIONCLOSE of type 0x1d (application close) is not sent in Initial or Handshake packets. So that's a drafting error, and we might reasonably take this as an editorial issue. However, if the question is about what a reaction to receiving an application CONNECTIONCLOSE in one of those packets, we might consider a different posture. If you get an application CONNECTIONCLOSE in an Initial packet that is otherwise valid, you probably want to drop the connection. And you probably don't want to start sending CONNECTIONCLOSE in response every time, because that leads to madness. But this is a general problem: if you detect and error and that error keeps being repeated, it probably isn't a good idea to generate a CONNECTION_CLOSE in response to every infraction.
(removing my comment as NAME posted what needs to be said couple of seconds earlier).
I'm going to re-close the can of worms I half-opened in my earlier comment and take this as editorial. From memory, the larger question of how to deal with junk is something we've discussed several times. If anyone wants to take that up, I'm happy to do that, but let's at least correct the obvious error.
It does make sense that we only allow 0x1c during the handshake.
NAME : Apologies, I misspoke -- I was speaking to interpretation of text, rather than the actual question itself.
Expands the definition of the resource set registration protocol, used by an RS to declare a resource set to an AS at runtime and receive a reference identifier for that resource set to hand to a client.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: f9aac0b2af163c0f9a58ba17e93db7e8956140bf :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Registering a Resource Handle: Editor's note: It's not an exact match here because the "resource_handle" returned now represents a collection of objects instead of a single one. Perhaps we should let this return a list of strings instead? Or use a different syntax than the resource request? Also, this borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol
This proposed text disallows specifying a flag extension where the response is a regular extension with content rather than a mere acknowledgment.
Well, I think of this as being the request extension. I can live with this if it's the WG consensus, but it seems like it would be useful to be able to say "I support largeish extension X" (we already have some such extensions) and it would be kind of sad if that took 4 bytes.
Seems strange to have to state this, but that's OK. Do you want to explain why? That is, because this results in a "response" extension appearing without a "request" extension, which is not permitted.
This should now consider and . There are no perfect solutions for these, but the solutions chosen should be close.
I don't agree wth some of this but agree with a bunch. I took carsten's changes for all the parts I agree with and put them in URL
I might suggest we pull that PR and then look at what is left (on a bunch of them it is simply if there should be an * suggesting don't use or not) then we can rebase this PR and see what is left to resolve.
Oops, I just changed my PR to react to your comments before seeing
Pushed another version that has both / and % for the same thing, where % is marked with a *
Now, instead of delete, it's "not recommend" and mentions kg as exception. I think this is good to merge.
The following units are questionable: % -- this looks like a percentage (0..100), but it is not (0..1). count -- what? This is about a dimensionless quantity? %RH, %EL appear to be percentages, but imply a quantity. EL may be a quantity, but the unit is second. In SI, we don't do new units for new quantities (there is no "millimeter radius" or "nanometer wavelength"). Bspl -- this really should be in dB (see ), SPL is the quantity again. beat/min, beats -- these should be 1/min (but see ) and 1 (dimensionless); how is beats different from count? We don't have bit (but bit/s), byte. 1/min is there only for heartbeats, not for revolutions ("rpm"). Should really be 1/s (but see ). lat and lon are a bit weird, too. (Celsius is also questionable -- the rationale of should call for all measurements being expressed in Kelvin.)
on on kevin vs C, every thermostat manufacture I can find has said they want C over kelvin. bunch of implementation are using 0 to 1 for light levels but imagine we could change % to 0 to 100 count - yep count :-) Bunch of sensors simply count pulses of who knows what. Totally agree this is not a unit but this is the pragmatic sort of thing needed EL is a great example of something that many sensors in sports have to deal with in common way.
They use this and it works well for them
So I changed % to mean percentage. Cel of course stays in (even though it is wrong wrong wrong :-). I have marked count and EL with the "not so recommended for new producers" range. But we don't really have a base unit for "1" (dimensionless) either. The problem remains that giving a unit doesn't tell you what quantity actually has been measured, and the trend to make more and more finer grained units for the same kinds quantities measured in different ways (as in psi vs. psig etc.) leads into the woods.
just finding all the email now … I think the thing that people like about this is it’s not a SI unit, it’s something that tells you something useful about what you are measuring across a wide range of devices. I think we need to think of these from a point of view of broadly useful than are they a SI unit. Agree with your slippery slope psi, psig, etc argument but all of those exist for a reason.
The SI unit for mass is kg. says: That leads to being unable to use the SI unit for mass, instead, we are using g. But then we are using derived units such as l (dm3) and l/s (dm3/s). So: We need to decide the above TODO. We need to decide whether to stick with SI units or allow simple names for derived units (gram, minute, liter). Domain-specific units are often weird (1/min = "rpm", mmHg or mol/dl in medicine, ...).
I think a key part of the registry vs existing SI unit tables was to be able to use things that were not proper units but agree things can be cleaned up. Clearly rpm and bpm have the same unit in the sense of what the dimensions are but what they are used to measure are pretty different and knowing that it is bpm often provides a level of information about how to process the information. As related to our whole conversation on why we needed the IANA table, the ability to have things in this that are not really a classic SI unit is the key value of SenML. The rules are just guidelines. If we want to change the unit of mass from g to kg, we can do that but the point on the prefixes was not to have both g and kg as that just reduces interoperability
Addressing Roman's AD comments.
has 2 conflicts, not sure how to resolve, the updates look fine. Please merge.
There was a conflict with the 8174 reference being in the other branch. I added it in because it's now part of the terminology paragraph.
Please address the following IDNits: -- The document seems to lack an IANA Considerations section. (See Section 2.2 of URL for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7525, but the abstract doesn't seem to mention this, which it should. Section 1. Editorial. -- s/RFC 5246 [RFC5246]/[RFC5246]/ -- s/RFC 6151 [RFC6151]/[RFC6151]/ -- s/RFC7525 [RFC7525]/[RFC7525]/ Section 1. Editorial. For symmetry with the rest of the text: OLD RFC 6151 [RFC6151] details the security considerations, including collision attacks for MD5, published in 2011. NEW In 2011, [RFC6151] detailed the security considerations, including collision attacks for MD5. Section 1. Please provide a reference for "Wang, et al". Is there a reference to provide for the "the potential for brute-force attack" Section 6. Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/ Section 6. Move the text "In Section 7.4.1.4.1: the text should be revised from" out of the "OLD" block of text to be its own intro paragraph so that the OLD vs. NEW is a clear cut-and-paste. Section 7. Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/ Section 7. SHA-1 is also not mentioned in RFC7525. Recommend: OLD The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated.
NEW The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated. Section 7. Editorial. Grammar. OLD In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used NEW In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used Section 10.2 Please make RFC5246 a normative reference.
This document should mention unidirectional streams Some words about the meaning of an abort signal vs. a clean close would be useful, both ingress and egress. Maximum stream bytes = 2^62-1. Saying "there are special streams for QUIC" is inaccurate (it's just one stream now, conceptually), and I would not bother to describe the CRYPTO frames this way.
Also: stream aborts are always unidirectional. what can/should applications assume about stream IDs? are they accessible, and does the app have any control over them?
Do we need to include the RFC7252 note for emphasis?
Probably not, as we are not changing anything about 5.10.1, are we? (But then 7.5 also points out a place where we maintain a property of 5.10.1.) ((But then, again, where would be put this?))
We need to identify the ABNF fragments as ABNF as in so they become easier to check in BAP.
We could add the note to Section 7, right after the new reference to "fragment":
Merged in abnf annotations from
is relevant to Section 7.
Good point. So I assume applying the same fix (add »[ "#" fragment ]«) four times to the ABNF in 7.1 to 7.4 would fix that? (We probably want to line-break before path-abempty in all four cases.)
If would be helpful to have more context for how the fragment identifier is used in CoAP. I don't see much detail in RFC7252 besides: Note: Fragments ([RFC3986], Section 3.5) are not part of the request URI and thus will not be transmitted in a CoAP request.
Fragment identifiers are not used in a transfer protocol; their use is a local matter on the client side. The mistake we made in RFC 7252 is providing ABNF that doesn't show fragment identifiers at all in the URI syntax. While CoAP as a protocol does not care about them, they are intended to be allowed in CoAP URIs so they can indeed be used on the client side. The note mentions this, but the ABNF does not reflect that. Same for coap-tcp-tls. Does it matter? The meaning of fragment identifiers is defined by the media type. So far, there has been little use of fragment identifiers in the media types being used with CoAP. Now, SenML actually does go ahead and defines a meaning for them, and other media types in the future might as well. So it would be good if the ABNF in the CoAP standards did not give the impression fragment identifiers cannot be used at all with CoAP URIs.
Note from Carsten: We may have to reopen that issue based on the about-face that the HTTP WG made here:
From URL which references: Absolute URI Some protocol elements allow only the absolute form of a URI without a fragment identifier. For example, defining a base URI for later use by relative references calls for an absolute-URI syntax rule that does not allow a fragment. absolute-URI = scheme ":" hier-part [ "?" query ] URI scheme specifications must define their own syntax so that all strings matching their scheme-specific syntax will also match the grammar. Scheme specifications will not define fragment identifier syntax or usage, regardless of its applicability to resources identifiable via that scheme, as fragment identification is orthogonal to scheme definition. However, scheme specifications are encouraged to include a wide range of examples, including examples that show use of the scheme's URIs with fragment identifiers when such usage is appropriate. and URL further states: Requirements for Permanent Scheme Definitions This section gives considerations for new schemes. Meeting these guidelines is REQUIRED for 'permanent' scheme registration. 'Permanent' status is appropriate for, but not limited to, use in standards. For URI schemes defined or normatively referenced by IETF Standards Track documents, 'permanent' registration status is REQUIRED. [RFC3986] defines the overall syntax for URIs as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] A scheme definition cannot override the overall syntax for URIs. For example, this means that fragment identifiers cannot be reused outside the generic syntax restrictions and that fragment identifiers are not scheme specific. A scheme definition must specify the scheme name and the syntax of the scheme-specific part, which is clarified as follows: URI = scheme ":" scheme-specific-part [ "#" fragment ] scheme-specific-part = hier-part [ "?" query ] On Jan 28, 2015, at 1:56 PM, Julian Reschke wrote: The answer is "no". URL I don't know how I got beaten into submission on that for RFC7230. ....Roy
NAME Please take a look at this updated text to see if it addresses your concerns.
To edit notification comments on pull requests, go to your .
Thinking about possible extensions to GNAP's interaction modes, I had the impression that the specification could be a bit clearer regarding requirements on such extensions. From reading Section 3.3, my understanding is that all implementations of GNAP, including ones using extensions which define additional interaction finish methods, MUST include a nonce in the grant response (given that the AS wants to use the finish method offered by the client instance): URL However, Section 3.3.5 sounds a bit different, only referring to the two interaction finish methods defined by GNAP core: URL Section 4.2 could be a bit clearer as to what is expected of future extensions to GNAP, it currently says: URL with the two following sections describing the finish methods defined by GNAP core. This is, however, somewhat clearer in Section 4.2.3: I.e., Section 4.2.3 implies that AS must (somehow) provide the client instance with an interaction reference and interaction finish nonce. But it may be helpful to make this more explicit throughout the relevant Sections. There seem to be no requirements for future interaction start methods. It may be helpful to document some minimal requirements, e.g., enough information to identify the grant has to be conveyed to AS via RO in the interaction start (such as the redirect URI in GNAP core).
Thanks NAME for taking the time! The proposed text looks good to me (just one possible typo, I'm not a native speaker, so I'm not 100% sure about that).
This PR begins filling in the IANA Considerations section, starting with a Ciphersuites registry. This addresses the concerns in as discussed at the interim (2019-10), namely by reserving for vendor use chunk of the code points space large enough to be selected at random without huge risk of collision (2^12 values). Depends on
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits.
:hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .*
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today
I fixed the grammar and added some text about "subsequent verification"
Also see URL
What's the issue?
Someone thought we should talk about how to parse SDP with more than one identity line and handle that. I did not look, we may already have whatever we need in the draft but I just opened this so we would at least go check.
JSEP practice is just to put in placeholders and link to the defining draft, so we should punt the actual semantics in security-arch.
See email to rtcweb from Stefan Håkansson subject "Identity in the SDP"
Sayeth Stefan: >[2] URL
This changes HTTPUNEXPECTEDFRAME, which is used only once, to HTTPFRAMEUNEXPECTED that is used multiple times.
During the London interim, it was noted that error codes refer to things being "malformed," "bad," "invalid," and "unexpected." Pick one and use it consistently, or establish precise definitions for each. This applies to both the current document and .
The three words are not equivalent: while both "malformed" and "invalid" are "bad," "malformed" is not the same as "invalid."
Minor correction here, "bad" is only used in . The only instance of "bad" in current document is a substring of example "0x1abadaba". I'll fix the PR before it lands, whatever order we end up doing things in.
The different value-judgement terms are corrected by the flurry of settings PRs that NAME already did. HTTPFRAMEERROR has replaced malformed, and UNEXPECTEDFRAME and WRONGSTREAM are reasonably descriptive (though see , ). We do still have some variation between HTTPTHINGDESCRIPTOR, HTTPTHINGERROR, and HTTPDESCRIPTORTHING (e.g. HTTPUNEXPECTEDFRAME versus HTTPREQUESTREJECTED) that might be worth reconciling. Is it worth turning into HTTPFRAMEUNEXPECTED?
Resolved by and something prior to it.
oops, thanks
cc NAME
NAME is the build expected to fail?
No, but the problem seem unrelated to your change, so we are all good.
Looks like it was a transient failure. Re-running resulted in success.
NAME points out that the HPKE version is not pinned. This is probably needed for interop. Version -07 should come sometime this week, so that seems like a perfectly fine version to use. I can send a PR when that version is cut.
Fixed by
Each line is limited to 72 characters.
I verified that this PR produces the draft that we expect. I did one small change: remove spaces at the end of lines.
There are many isntances in the markdown source where a whole paragraph is entered in a single line of text. This makes the reviewing harder, and messes up the "what changed" view when reviewing PRs.
Just to be on the same page, how should we format the text? I see two possible ways. Hard-constraint the number of characters per line to a given limit (e.g., 80) Make one sentence = one line I have a slight preference for option 2, but I can of course live with the other or a mix of both.
I would prefer something like 72 characters, because the last 8 positions are used for numbering the cards in your deck.
I find this pretty hard to read, but assuming I am reading it corectly, it basically says that if you read any packet or write any packet that has a frame other than ACK or padding, then you reset the timer. The text about "other packet has not been acknowledged or lost" doesn't make sense unless you have some very complicated timer scheme, because the packet won't be acknowledge or lost until after it is sent, at which point I have already reset the timer.
Yeah, this is opaque. I think that the logic is something like: when receiving a packet, restart the idle timer when sending an ACK-eliciting packet. if you haven't sent other ACK-eliciting packets since the idle timer was started, restart the idle timer That is, if you send 10 packets, only the first of those restarts the timer. This clearly needs to be reworded.
I'd suggest one change to the second bullet, Martin. "when sending an ACK-eliciting packet. if you haven't sent other ACK-eliciting packets since the idle timer was restarted due to a received packet, restart the idle timer" And yes, that text is not clear.
I like the look of the wording change in ac59e11. Is there something blocking it from being applied?
Nothing. I just neglected to open the pull request. That happens sometimes. Lots of changes in flight...
I think this looks good, but NAME has more familiarity with this code than I do, so I'm adding him as well.
Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.