jiebi/CodeConvo huggingface dataset:
Code change:
and <del> fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. </del> <ins> fields ought to be recognized by all HTTP implementations whether or not they advertise conformance with HTTP/1.1. </ins> New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients

Related discussion:
text: Recently I noticed that the host header field is being discussed in . I believe that we should move the definition of the host header to the HTTP/1.1 messaging draft, and discuss about "authority" as a concept in the semantics draft, as the "host" header is specific to HTTP/1.1 (except for handling of broken HTTP/2 clients)?
Hi Kazuho, We discussed this on the editors' call. Host's semantics aren't specific to HTTP/1.1, even if its requirements are different in other protocol versions. That's why we moved it to Semantics; it's not version-specific (and really very few headers should be). Closing; if you feel it needs more discussion please request re-opening and we'll do so.
Thank you for the consideration. While I do understand the argument that the semantics of the header field is not version specific, the use is. I've opened a PR that tries to clarify that.
Thank you for the changes!
Code change:
and <del> fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. </del> <ins> fields ought to be recognized by all HTTP implementations whether or not they advertise conformance with HTTP/1.1. </ins> New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients

Related discussion:
text: by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.
Code change:
the "*expires" identifier. Its canonicalized value is a Decimal String containing the <del> signature's Expiration Time expressed as the number of seconds since the Epoch, as defined in Section 4.16 [3] of POSIX.1. </del> <ins> signature's Expiration Time expressed in "Unix time". </ins> 2.6.

Related discussion:
text: reuses existing definitions for S-F and Unix time.
Doesn't make this PR redundant? (or regressive, really, because references the exact definitions to use - and from structured headers)
This probably
Code change:
by the user (e.g. a force reload). The immutable extension only applies during the freshness lifetime of <del> the response.  Stale responses SHOULD be revalidated as they normally would be in the absence of immutable. </del> <ins> the stored response.  Stale responses SHOULD be revalidated as they normally would be in the absence of immutable. </ins> <del> The immutable extension takes no arguments and if any arguments are present they have no meaning.  Multiple instances of the immutable extension are equivalent to one instance.  The presence of an immutable Cache-Control extension in a request has no effect. </del> <ins> The immutable extension takes no arguments.  If any arguments are present, they have no meaning, and MUST be ignored.  Multiple instances of the immutable extension are equivalent to one instance. The presence of an immutable Cache-Control extension in a request has no effect. </ins> 2.1.

Related discussion:
text: Editorial stuff, mostly line wrapping and adjusting terminology. Happy to chat through it if you like.
thanks for this
Code change:
>> Response: <del> 8.8.4. In responses to GET or HEAD, an origin server: In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a value in successful responses to a retrieval request. A client: </del> 9. 9.1.

Related discussion:
text: … (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.
Code change:
2.2. <del> The ABNF (Augmented Backus-Naur Form) syntax for the Tunnel-Protocol header field is given below.  It is based on the Generic Grammar defined in RFC7230. </del> <ins> The ABNF (Augmented Backus-Naur Form) syntax for the ALPN header field is given below.  It is based on the Generic Grammar defined in RFC7230. </ins> ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230) MUST

Related discussion:
text: Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.
Code change:
6.7. A subscriber issues a "UNSUBSCRIBE" message to a publisher indicating <del> it is no longer interested in receiving media for the specified track. </del> <ins> it is no longer interested in receiving media for the specified track and Objects should stop being sent as soon as possible.  The publisher sends a SUBSCRIBE_DONE to acknowledge the unsubscribe was successful and indicate the final Object. </ins> The format of "UNSUBSCRIBE" is as follows:

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

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

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

Related discussion:
text: A client connected to the relay and subscribed to a track, which fowarded the subscribe to a publisher. The track was published to the relay and ended with a FIN. Another client subscribes to this track from the beginning (Absolute/0,0) and no end. Does the relay need to resubscribe upstream? Now suppose that the connection from the publisher to the relay closed abruptly, or the track was terminated with SUBSCRIBE_RST. This is a signal to the relay that it's worth another subscribe to find out where the end of the track is. I can live if we consolidate the framing to a single message, and define a special error code to mean FIN, but I do think the transport needs to see the difference.
I like it. I would also like to merge ERROR with CLOSED, but we'll chat about that.
Code change:
<del> A Client authenticates with the Transparency Service, to Register Signed Statements on behalf of one or more Issuers. Authentication and authorization is implementation-specific, and out of scope of the SCITT Architecture. </del> <ins> A Client authenticates with the Transparency Service before registering Signed Statements on behalf of one or more Issuers. Authentication and authorization are implementation-specific and out of scope of the SCITT architecture. </ins> <del> The Transparency Service MUST syntactically validate the Issuer's identity Claims, which may be different than the Client identity. </del> <ins> The Transparency Service MUST perform signature verification, as defined in RFC9052, and MAY perform additional checks as part of its Registration Policy. </ins>

Related discussion:
text: This is not correct if we also consider SCRAPI
SCRAPI says Auth is, may or isn’t required on specific endpoints, but doesn’t specify how it’s implemented. Is that inconsistent?
please check my suggested changeLGTMok with changes to 4.3 step 2LGTM
Code change:
If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. <del> This may require buffering the responses to preserve ordering in HTTP/1.1. </del> The server can cause a client to retry a request and not use early data by responding with the 425 (Too Early) status code (status),

Related discussion:
text: Hopefully none of this collides with other PRs in flight.
I think it's fine with this. Adding a bit of pragmatism as you did in the last commit also reminds that the low cost of retrying is not worth a lot of trouble :-)
Code change:
prefixed name and length-prefixed value; see fields. The format allows for the message to be truncated before any of the <del> length prefixes that precede the field sections or content.  This reduces the overall message size.  A message that is truncated at any other point is invalid; see invalid. </del> <ins> length prefixes that precede the field sections or content; see padding. </ins> The variable-length integer encoding means that there is a limit of 2^62-1 bytes for each field section and the message content.

Related discussion:
text: Basically, it saves the effort of writing stuff that you know to be empty. It's not a critical feature, but it turns out to be a simple way to deal with not sending trailers or a body. In the extreme, you can also drop headers to produce the simplest and shortest HTTP message ever: 0x0140c8. CLoses .
Hey David, I've made some larger edits here to factor the truncation text better. I've included your normative language.
The draft mentions that messages can be truncated in some places, but not in others. I think it would help to explain why one would want to truncated a message.
This is really just a neat way to avoid having to write out all of the pieces of a message. So if you don't have trailers, it's OK not to say "I have 0 trailers". The decoder is required to deal with it. Before you say "that's hard", you don't need to change the parser to deal with truncation. Adding three zero-valued bytes to the end of any message you receive does the job just fine. If it isn't truncated, those will be treated as padding.
Thanks
Code change:
bottleneck link in one round-trip or less.  As noted in BBRDrainPacingGain, any value at or below 1 / BBRStartupCwndGain = 1 / 2 = 0.5 will theoretically achieve this.  BBR uses the value 0.35, <del> which has been shown to offer good performance on YouTube, when compared with other alternatives. </del> <ins> which has been shown to offer good performance when compared with other alternatives. </ins> 2.6.

Related discussion:
text: Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.
Code change:
Let value be Boolean true. <del> Let parameters be an empty, ordered map. </del> <ins> Let parameters be the result of running Parsing Parameters parse-param with input_string. </ins> Let member be the tuple (value, parameters).

Related discussion:
text: Ping NAME
LGTM from here, thanks!
Julian asked in e-mail why we can't have a dictionary with a default True value that is parameterised:
I think we could replace: With:
NAME NAME NAME thoughts?
Example-Field: ;param=on-default-boolean Is this a dictionary? What is the key here? (I see that the value is supposed to be implicit true, but I'm not grokking the implied syntax) If I ignore that (assuming I've misinterpreted something), I like the idea of allowing implicit True. The serialization algorithm needs a bit more surgery to support this as the canonical form, probably replacing: with something like: (unless we also modify Serializing an Item to optionally omit True values, but we can't just do that unconditionally, or else a simple Item header would be empty if True.) This is the same issue as URL, I think -- back in December you thought that it would take more drastic changes. If this is everything that it needs, though, it seems reasonable. None of the canonical tests break with this (except for a couple of serialization tests, which just need to be updated), and I don't see any obvious cases that would be parsed incorrectly.
Sorry, that was unrelated, accidentally copied from the email. Ignore. I'll work up a PR and see how it looks.
Awesome. Now, how about also collapsing the "false" value a bit. So instead of having a=?0 just say !a ?
IMHO explicit is better than implicit: I am not sure that is a good choice. I am not even sure that defaulting is a good choice.
Tantalizingly close to making Dictionary a superset of List. I can't think of anything that would break.
Code change:
7.3. Assume the client wants to get the contents of the update item on <del> edge 0 to 101.  The request is: </del> <ins> edge 0 to 101.  The format of the request is shown in ex-ge. </ins> <del> And the response will be: </del> <ins> The response is shown in ex-get-res. </ins> 7.4.

Related discussion:
text: Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.