jiebi/CodeConvo huggingface dataset:
Code change:
there will be no "lock icon"). By its nature, this technique is vulnerable to active attacks.  A <del> mechanism for partially mitigating them is described in http-tls.  It does not offer the same level of protection as afforded to "https" URIs, but increases the likelihood that an active attack be detected. </del> <ins> mechanism for partially mitigating them is described in http-tls. </ins> 1.1.

Related discussion:
text: for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.
Code change:
The topology layer can also represent what needs to be managed by a specific user, for example IGP layer can be of interest to the <del> operator troubleshooting or optimizating the routing, while the </del> <ins> operator troubleshooting or optimizing the routing, while the </ins> optical layer may be of interest to the user managing the optical network.

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits
Code change:
is "/.well-known/oauth-protected-resource".  The syntax and semantics of ".well-known" are defined in RFC5785.  The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry <del> IANA.well-known. </del> <ins> IANA.well-known.  Examples of this construction can be found in PRConfigurationRequest. </ins> Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well-

Related discussion:
text: cc NAME
From Pieter's review: "between the host and path components of the protected resource's resource identifier, as shown in Section 3.1 below"
Looks good to me.
Code change:
3. The Variant-Key HTTP response header field is used to indicate the <del> value(s) from the Variants header field that identify the </del> <ins> values from the Variants header field that identify the </ins> representation it occurs within. <del> Each value indicates the selected available-value, in the same order as the variants listed in the Variants header field. </del> <ins> Each member of the list contains the selected available-value(s), in the same order as the variants listed in the Variants header field. </ins> Therefore, Variant-Key MUST be the same length (in comma-separated members) as Variants, and each member MUST correspond in position to

Related discussion:
text: For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)
Code change:
claim in the JWT.  Use of the JWT VC Issuer Metadata is OPTIONAL. Issuers publishing JWT VC Issuer Metadata MUST make a JWT VC Issuer <del> Metadata configuration available at the path formed by concatenating the string </del> <ins> Metadata configuration available at the location formed by inserting the well-known string </ins> <del> to the </del> <ins> between the host component and the path component (if any) of the </ins> claim value in the JWT.  The

Related discussion:
text: also add associated IANA registration request and fix up formatting etc in other IANA bits see it live URL
There are 2 parts of the draft discussing the path to issuer metadata: and I do believe the latter is the currently intended /.well-known mechanism, whereas the first section was probably not updated and would result in to resolve metadata. I guess this was an oversight in ?
Thanks for catching the inconsistency NAME and I believe you are correct that the latter is currently the intended mechanism for .well-known.
We might also want to use something other than "user" in the example path. It's not wrong exactly but maybe unnecessarily misleading or confusing.
endeavors to fix this (and a few other little things)
lgtm
Code change:
<del> HTTP SEARCH Method </del> <ins> The HTTP QUERY Method </ins> draft-ietf-httpbis-safe-method-w-body-latest Abstract <del> This specification updates the definition and semantics of the HTTP SEARCH request method originally defined by RFC 5323. </del> <ins> This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. </ins> Editorial Note

Related discussion:
text: The issue discussion also mentioned the ability for the server to indicate a GET-able URI for the returned results, presumably using Content-Location. It looks like the definition in -semantics is probably sufficient, but it's probably worth highlighting that there are caching implications to having that header present in one of these responses.
Content-Location doesn't have any effect on caching. It would be odd to add caching implications to it.
NAME I was recalling this: URL thinking that the response should be cached for the indicated resource. But I had missed this: And indeed, the Caching spec talks only about invalidating any existing entry for the indicated resource, rather than giving any permission to cache the response under that URI. The application is allowed to update its local copy based on Content-Location, but apparently caches aren't.
We should figure out/document: 1) Establishing the cache key - a cache needs to know how to compute a cache key for the request. The obvious (and very inefficient) way to do this is to use the entire request body as part of the key. 2) Request canonicalisation - we should allow caches with knowledge of canonicalisation algorithms for a given format to use them. 3) Indicating canonical form in requests - if a client (UA or intermediary) canonicalises, it would be nice if they could assert that in the request, so a downstream cache can assume it's there and just look for a byte-for-byte match, rather than re-canonicalising. This would allow a client to manufacture cache misses, but that's already possible in URLs... 4) Indicating cache key in requests - E.g., a hash of the request body. Needs security analysis, though. 5) Indicating cache key in responses - If the server can instruct caches as to what future requests would match it, that would be very advantageous. Necessarily requires knowledge of the request format, but we could define common ones for url encode, XML, JSON.
I don't think that (4) is generally feasible. There might be cases where a cache trusts other entities sufficiently that a hash (Digest field?) can be used, but it will need to work this out for itself. This is probably the big cost associated with caching this method.
Code change:
<del> HTTP SEARCH Method </del> <ins> The HTTP QUERY Method </ins> draft-ietf-httpbis-safe-method-w-body-latest Abstract <del> This specification updates the definition and semantics of the HTTP SEARCH request method originally defined by RFC 5323. </del> <ins> This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. </ins> Editorial Note

Related discussion:
text: As for the general case of c14n, it's unfortunate that this is necessary, but it is probably better than relying on having some shared understanding of an abstract model for the resource representation. I would not build this on any assumption that XML c14n is possible. A complete solution there is likely impossible. I know less about the warts of JSON, but even that is entering into dangerous territory. You might get more traction with schema-aware c14n with the understanding that it is not generally applicable to any document. That is, define tools so that specific XML- or JSON-based formats can opt in to the use of c14n. People might then apply that c14n if the format allows it; people might also apply the c14n if the format does not, but we have not promised them anything and so guarantees might not apply.
nod there's going to be a tradeoff between the amount of knowledge/processing necessary for c14n and cache efficiency. It might be good to explore what conventions a format needs to follow to make it easily canonical; I can't help but think that most use cases for this are going to be defining a new query language, not reusing an existing document or even data format.
I think that caching is a "must have", though probably we could just provide minimal hints and leave clients the onus of hitting the cache (eg. clients c14n-izing requests in some may increase cache hits). I won't mess with the request media-type (json? xml? x-www-form-urlencoded? ...) and just use the content checksum (eg. ). I think that supporting media-type aware caches is really hard to implement (eg. see rfc8785 and rfc7493 only for json): there's room for experimental specs though... That's ok, though see (2) about supporting media-types is hard Agree wrt Security Considerations IF we want to support a caching based on a response cache key, this could be implemented with some caveats without re-sending the at all: Authentication information should be processed; MUST NOT contain authnz information
Caching will be tricky for "similar" requests sent by different clients. On the other hand, caching could be simple for requests that are repeated by the same client (like in a refresh operation).
Code change:
<del> HTTP SEARCH Method </del> <ins> The HTTP QUERY Method </ins> draft-ietf-httpbis-safe-method-w-body-latest Abstract <del> This specification updates the definition and semantics of the HTTP SEARCH request method originally defined by RFC 5323. </del> <ins> This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. </ins> Editorial Note

Related discussion:
text: For this use case, we just need a way for the server to also point to a GETtable resource (maybe with a lifetime). If we solved that problem, would we still need full cacheability?
Needs to sync with .
Code change:
<del> HTTP SEARCH Method </del> <ins> The HTTP QUERY Method </ins> draft-ietf-httpbis-safe-method-w-body-latest Abstract <del> This specification updates the definition and semantics of the HTTP SEARCH request method originally defined by RFC 5323. </del> <ins> This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. </ins> Editorial Note

Related discussion:
text: (opening this so it has a discussion venue) Currently, the spec uses "SEARCH" (for the reasons given in the spec). Alternatives: 1) pick a new name 2) use GET with payload (probably unrealistic, just listed for completeness) 3) use POST and find a way to label it as safe 4) re-use another existing safe method that takes a body (PROPFIND, REPORT) (just listed for completeness) The obvious drawback in "pick a new name" is the forseealke bike-shedding.
Just my .02. Using is initially attractive because it's familiar; effectively we'd be extending the semantics of the method with a header. However, I'm not sure it's a good idea. implies certain guarantees to clients, servers and intermediaries -- e.g., write-through. If an extension can change those guarantees, it's important that they're visible to all components, and an extension (e.g., a header) by nature can't guarantee that. It seems to me that one of the critical things to do is to get a positive indication from the user agent that the request they're sending doesn't have write-through, so a extension would need to carry an indication from the client. However, the origin server is also likely to need to convey a cache key and perhaps additional information, which leads this approach to something that's looking complex; the client has to send a certain header, the server has to send a certain header, and an intermediary still might not understand what's going on (which might be good or bad). So that makes me lean towards the status quo, (1), or (4) as being more straightforward. Reusing an already-deployed name has been discussed elsewhere; I'm not convinced that it's going to add a lot of value, considering that most traffic is HTTPS now and so intermediaries with fixed lists of supported methods are much less common. If we had data that they'd get through e.g., an enterprise virus scanning proxy whereas a new method wouldn't, I'd be interested to see that. Still, if fits the bill adequately, I think it's fine. The real test will be whether folks (especially HTTP API developers) find it compelling enough to use; I'm not sure quite gets there, but it's in the ballpark. If we're going to consider new names, I'd suggest .
Code change:
<del> HTTP SEARCH Method </del> <ins> The HTTP QUERY Method </ins> draft-ietf-httpbis-safe-method-w-body-latest Abstract <del> This specification updates the definition and semantics of the HTTP SEARCH request method originally defined by RFC 5323. </del> <ins> This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. </ins> Editorial Note

Related discussion:
text: If the point of this exercise is to make safe-ness visible to intermediaries, then a method is the right place to put that signal. I'm comfortable enough with , though an entirely name would be equally good. (I think that we should continue discussion about cache keys separately.)
I value a lot the ability for intermediaries to filter out write requests before they reach an application. Reusing won't have this advantage.
Interim discussion: switch document to use , which has good support from the attendees, and see how it seems to people who would be adopting.
Que? This is far more than the simple rename I was expecting. I had a similar double-take on first read, but most of the additional changes appear to be excising the WebDAV references, which is reasonable to do along with the rename.
Code change:
compatible assigned to the nominated registrations, prefixing each with "*" to indicate that it is a retrofit type. <del> Then, add the field names in new-fields, with the corresponding Structured Type as indicated, a status of "permanent" and referring to this document. </del> Finally, add a new column to the "Cookie Attribute Registry" established by COOKIES with the title "Structured Type", using information from cookie-params.

Related discussion:
text: Sorry for noticing this so late. I don't think the security considerations of in retrofit work out. (Also CC NAME who is much better at web security than me.) If we introduce two ways to spell some field, we need to worry about whether this can allow various issues when sender and receiver don't agree on what's going on. The draft mostly leaves this to the future, but it does include some about this: This seems to put the onus on the sender, not the receiver. If you don't know the receiver accepts the alternate representation, you can't send it. It includes no corresponding receiver obligation, I guess on the assumption that if you see SF-Cookie, you can assume the sender meant it? I don't think that works. In a browser, the sender is a combination of browser logic (which has the final say) and JS (with a complex trust relationship). The browser logic specifies some which JS cannot set. Other HTTP systems have similar splits: an HTTP serving frontend may get fields from a CGI script or act as an intermediary, but it cannot allow the downstream code to specify fields like . These rules typically look like a blocklist with the default behavior to pass fields through. All this is to say, browsers won't let JS set the field directly, but setting is perfectly fine, up to CORS rules. A receiver may see that text and incorrectly assume that processing is fine, breaking some cookie invariants. Or vs , which will break some sites' CSRF processing. Beyond just blocklists, a retrofit-unaware HTTP cache that processes caching fields but passes through other fields will likely make a mess of the mapped caching fields. If we prefixed the names with , that would at least meet the browsers' rules, though I worry it'll still break other intermediaries. It's also a little unsatisfying of a fix. We could say that a receiver cannot process these either unless it's received some explicit negotiation that the sender knows about this. That's vague and unspecified, but probably would work, depending on what the intent is here. This is a bit handwaivy because I'm not sure what the use cases are here. But if we require explicit sender and receiver negotiation, it's unclear what we're getting out the parallel field names in the first place. It seems to me that's where all this risk comes from.
Code change:
compatible assigned to the nominated registrations, prefixing each with "*" to indicate that it is a retrofit type. <del> Then, add the field names in new-fields, with the corresponding Structured Type as indicated, a status of "permanent" and referring to this document. </del> Finally, add a new column to the "Cookie Attribute Registry" established by COOKIES with the title "Structured Type", using information from cookie-params.

Related discussion:
text: Giving alternate names interferes with pass-through logic across the pipeline. Maybe we can get a more robust story, inspired a bit by (I'm just assuming this is one of the main use cases here) is to say: The text representation of is what it is. If this part of the system uses the text form, use the existing syntax The structured field representation of is this mapped thing. If this part of the system uses structured fields, use that syntax At boundaries where forms change, convert. We need to be a bit careful about fallibility here, but perhaps: Conversion from text to other forms is allowed to fail, since you can just fallback to the text form. Conversion from other forms to text probably needs to be stricter? The difference between mapped and normal fields is the structured field and text representations don't directly align, so they need to be treated a bit special Like I said, this is handwaivy and definitely incomplete. But it feels to me like something in this might be more sound. It makes it more obvious we have to be sure what representation we're using at each layer and there's no risk of one side thinking something is a generic header and another thinking it's an alternative representation of a special header.
This seems like a plausible risk to me. I'm not as familiar with non-browser use cases, but I can certainly imagine confusion that would result from clients being able to create mismatches between and . I can imagine ways to deal with this in browsers (in addition to NAME suggestions, we could add as a , just as we've done for and ). It's unclear how helpful that would be for non-browser usecases.
Main nuisance with prefix is that, on the receiver side, you don't know a priori if the client is an updated browser, which knows about the prefix, or a preexisting browser which does not. I suppose you could do UA sniffing, but let's not design a system that requires UA sniffing to work if we can help it! :-)
That's fair. would be safe without a change to Fetch. Still, given my expectations about the current deployment of mapped fields, I think we could reasonably get ahead of them in the browser world. Not at all sure about the rest of the ecosystem...
I like the direction that if you've already negotiated support, you could just replace the legacy headers with their spiffy (SFfy?)
Code change:
compatible assigned to the nominated registrations, prefixing each with "*" to indicate that it is a retrofit type. <del> Then, add the field names in new-fields, with the corresponding Structured Type as indicated, a status of "permanent" and referring to this document. </del> Finally, add a new column to the "Cookie Attribute Registry" established by COOKIES with the title "Structured Type", using information from cookie-params.

Related discussion:
text: new equivalents using the same names, and if you haven't negotiated support then you have no business sending these variants and expecting them to work. Of course, that means this draft probably can't get away with "We don't define a way to negotiate this, but you do that."
I think we'd avoid needing "OUGHT TO" in that model. That model is more explicit that these are two incompatible representations of these fields. The negotiation requirements become more straightforward, I think: E.g. draft-nottingham-binary-structured-headers meets this requirement because you set a flag on the message, and gates usage on a setting. A hypothetical SF-based HTTP API would also meet this requirement because it's unambiguous that takes some in-memory structured field representation.
Hey David, Yes, I've been somewhat concerned about the potential issues in this area for a while. Minting new field names for the alternative forms was the initial approach, but I was half expecting someone to raise this issue :) One thing: No; the assumption is that a recipient sees SF-Cookie, they'll ignore it unless they've positively opted into it meaning something. Perhaps, as you point out, that should be more explicit -- e.g., say that these fields MUST NOT be processed unless the sender does [magic]. Making sure that evidence of [magic] is propagated properly may be tricky, though. I could also see removing the new field names. That should work for many contexts, although I suspect it might make handling the new forms difficult in some. Prefixing with doesn't seem very attractive to me.
Ah interesting. So I guess the middle option, "require explicit negotiation on the receiver" was actually the intended interpretation. That's not how I read the draft. It says "implementations are prohibited from generating such fields unless they have negotiated support for them with their peer" without saying anything about the recipient's responsibilities. So it sounds like, at minimum, we should update the draft. Getting that right in the presence of a chain of intermediaries is quite subtle however. Suppose we go A -> B -> C and both B and C support mapped fields, but A does not. B must be careful not to forward along a mapped field from A. E.g. it might decline to advertise mapped field support to C because A doesn't support it.