jiebi/CodeConvo huggingface dataset:
Code change:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and

Related discussion:
text: Imagine in the worst case that 1 million requests are made within 100ms to a (really powerful) edge. That edge would only forward one request to the origin. All the rest would be held pending that response. This is exactly what happens when a few million people ask for a live HAS stream. Due to fan out and request coalescing, the CDN only sends a few requests back to the actual origin.
Yeah exactly. Only the first SUBSCRIBE will propagate upstream and the SUBSCRIBEOK is used to bootstrap the live edge. The relay can infer the live edge while the single upstream subscribe remains active. Because of the SUBSCRIBEOK, the relay knows that the received OBJECT only gets forwarded to the first downstream subscribe. Otherwise it would have to guess the live edge. The relay keeps track of while the upstream subscription remains active. The initial value is set by but all future updates are based on received messages. This way is can map from relative->absolute and reply with without issuing a new upstream subscription.
For the original use-case reported on this issue, if there are multiple subscribes at a relay with varying relative offsets, the relay has no choice but to send each combination of subscribe and a given -ve relative offsite upstream since that identifies each unique data point in the track. This has couple of issues it doesn't scale across relays and also when there are very high rate of subscriptions across relays and clients it makes the lookup and state management complicated latencies across relays and client locations ends up producing varying results for the same query since it depends on when the query was made and how long would it take to for conferencing cases when there are multiple publishers who can be active (have live edge), unjoined yet ( so no live edge) , the expectation for subscribes to get a OK back from original publishers will not scale in terms of latency of joins The more i think of it, subscribing back into paste using a relative offsets and expecting the answer to be vetted by the original publisher "unnecessarily complicates the protocol".
The group sequence numbers are consistent between subscriptions . If a relay receives relative subscribes of -5,-3 and -1, all it has to is send a single subscribe upstream of -5. The response would give it the live edge group as well as all the content for the various subscriptions.
Code change:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and

Related discussion:
text: If the subscriptions were -345, -2, -1, the relay could decide to make two subscriptions upstream - one for -345, the other for -2, because it didn't want to force the smaller relative subscriptions to wait for the larger one. The point is, this is optimization logic for the relay. It does have a choice in what subscriptions it sends upstream based on the timing and diversity of the input subscriptions. Why is the latency of the join affected? Consider a subscriber talking to an edge where the subscriber is 100ms away from the origin. We consider two scenarios: in the first case the subscriber receives a SUBSCRIBEOK immediately after subscribing but then waits 100ms for the audio and video to arrive from the origin. In the second case the the subscriber waits 100ms to receive SUBSCRIBEOK but it is immediately followed by the audio and video. So in both cases the subscriber gets its audio and video after 100ms. The media latency is consistent under either scenario.
If the relay logc is to send only a single subscribe upstream, then you don't need anything to be said in Subscribe OK either. Since when the first object arrives it can compute the live edge by adding 5 to the object being reported and the compute the absolute values for others (in this case for -3 and -1). That would definitely make things simpler for sure.
For cases where a client wants to go back 345 groups in past, i will be very much inclined to do an absolute request after learning the latest known state of the group as an end application OR something catalog can describe more information to make the right absolute request on the first go
It can't do this because the order of items it receives as Streams is not guaranteed. The origin may send the groups in order -5,-4,-3,-3,-1, but they could be received at the relay (or any hop) as -3, -5,-4,-1,-2. That's why you need an explicit notification from the origin as to where the live edge is. Only that plus the group sequence numbers allow the correct sequencing, not the order of arrival.
In this case there was just a single subscribe request with -5 was sent upstream, based on your explanation above. This avoids all the confusion which would happen when there are multiple inflight -ve offsets.
This seems like it will have many race conditions.
Code change:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and

Related discussion:
text: It seems like it would be better to transfer this in the STREAMHEADERTRACK and equivalent. Thoughts on that ? I also worry about how long a subscribe would wait to find out this information - that seems like it could be problematic for the client knowing when to give up on a subscribe. Hopefully we can discuss in Denver
Code change:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and

Related discussion:
text: Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)
Code change:
If a DELETE method is successfully applied, the origin server SHOULD send <del> A client SHOULD NOT generate content in a DELETE request.  Content received in a DELETE request has no defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request. </del> <ins> Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (request.smuggling).  A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.  An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. </ins> Responses to the DELETE method are not cacheable.  If a successful DELETE request passes through a cache that has one or more stored

Related discussion:
text: Actually it is even already used and documented: the broadly used ElasticSearch explicitly documents how to perform JSON search requests using : URL So please let's stick to "SHOULD NOT" with Julian's "unless negotiated via other means" or something like this, instead of suddenly adding dangerous exceptions to the protocol and breaking interoperability between already deployed and working components.
Code change:
1. <del> The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol.  However, the way HTTP/1.1 uses the underlying transport (HTTP11) has several characteristics that have a negative overall effect on application performance today. In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection.  HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking.  Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency. </del> <ins> The performance of applications using the Hypertext Transfer Protocol (HTTP) is linked to how each version of HTTP uses the underlying transport, and the conditions under which the transport operates. Making multiple concurrent requests can reduce latency and improve application performance.  HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection.  HTTP/1.1 (HTTP11) added request pipelining, but this only partially addressed request concurrency and still suffers from application-layer head-of-line blocking.  Therefore, HTTP/1.0 and HTTP/1.1 clients use multiple connections to a server to make concurrent requests. </ins> Furthermore, HTTP fields are often repetitive and verbose, causing unnecessary network traffic as well as causing the initial TCP TCP

Related discussion:
text: thanks both, good suggestions
... and HTTP/2's positives too! protocol. However, the way HTTP/1.1 uses the underlying transport ([RFC7230], Section 6) has several characteristics that have a negative overall effect on application performance today. a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency. I think time has shown these claims to not be great. How about cutting cruft and saying and then a tweak to a later paragraph in the intro to state that no one is perfect
It looks like you have a pull request that is dressed up as an issue :)
If you're receptive to change, I am willing to try and edit horrible XML
One change and I'm happy
Code change:
5.1. <ins> Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection.  Each major version of HTTP defines its own framing mechanism. HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end each response.  For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early.  For that reason, almost all modern implementations use explicit framing in the form of length- delimited sequences of message data. A message is considered when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete. 5.2. </ins> Every HTTP message has a protocol version.  Depending on the version in use, it might be carried in the message explicitly, or it might be inferred by the connection that the message is carried on.  A message

Related discussion:
text: I think this should be something like "Message Framing and Incomplete Messages", and should be after the headers / payload / trailers sections.
Code change:
3.3.2. <del> Floats are decimal numbers with an integer and a fractional component.  The fractional component has at most six digits of precision.  Additionally, like integers, it can have no more than fifteen digits in total, which in some cases further constrains its precision. </del> <ins> Decimals are numbers with an integer and a fractional component.  The Integer component has at most 12 digits; the fractional component has at most three digits. </ins> <del> The ABNF for floats in HTTP headers is: </del> <ins> The ABNF for decimals in HTTP headers is: </ins> <del> For example, a header whose value is defined as a float could look </del> <ins> For example, a header whose value is defined as a decimal could look </ins> like: 3.3.3.

Related discussion:
text: (Related to now-closed ) Should implementations be able to store parsed floats in IEEE754 binary64? And if so, should we expect that they round trip between parsing and serialization? It seems like the current limits were designed to support that notion, but there are cases where they do not. (Note, this isn't about being able to serialize arbitrary C++ doubles; the spec sensibly only supports a tiny subset of all possible 64-bit floats. This is about whether should always be true) IEEE 754 guarantees that if a string with no more than 15 digits is converted to a double and then back to a string, it should result in the original string, but that appears to require rounding in some cases; truncation, which the serialization algorithm calls for, can change the string representation. Parsing the string "12345678901234.1" as a float, for instance, results in a binary64 representation with value 0x42a674e79c5fe433, whose exact decimal expansion is 12345678901234.099609375. Following the text of the serialization algorithm, will be 1, and so the number will be serialized as "12345678901234.0" It appears, as an implementer, that the only way to ensure that a float parsed from a valid string can be serialized back to the original string is to store it as a fixed point decimal in two parts, or else use a float with >64 bits of precision for storage.
Would it be adequate to change truncation to rounding in step 9 of Serializing a Float?
That's a can of worms. Which rounding? (nearest-or-even, nearest-or-away from zero, to zero, up, down?)
I know nearest-or-even is the recommended rounding technique. Can we specify that?
Round, nearest-or-even, to fractionaldigitsavail digits? While we're at it, should the spec be stricter about trailing zeros? My implementation currently strips any trailing zeros after the first position past the decimal point (so 1.230000 is serialized as 1.23, but 1.000000 is serialized as 1.0, as is 1.0000001, after rounding/truncation), which passes the test cases in URL The spec just says "at most fractionaldigitsavail digits, but that allows multiple "correct" serializations of a given float.
Code change:
3.3.2. <del> Floats are decimal numbers with an integer and a fractional component.  The fractional component has at most six digits of precision.  Additionally, like integers, it can have no more than fifteen digits in total, which in some cases further constrains its precision. </del> <ins> Decimals are numbers with an integer and a fractional component.  The Integer component has at most 12 digits; the fractional component has at most three digits. </ins> <del> The ABNF for floats in HTTP headers is: </del> <ins> The ABNF for decimals in HTTP headers is: </ins> <del> For example, a header whose value is defined as a float could look </del> <ins> For example, a header whose value is defined as a decimal could look </ins> like: 3.3.3.

Related discussion:
text: It's also weird to only require roundtripping for floats that can be represented in binary64. The simplest might solution here might be to just accept that floats are lossy. If an implementer needs precision, use a string. This trade-off seems to work well enough for JSON parsers.
The spec already restricts floats to those which can theoretically be round-tripped into a binary64 and back; this is just about ensuring that that actually happens, if a binary64 is used as the backing store (which is natural for at least C++ and JS implementations)
nearest-or-even SGTM. Stripping trailing zeros as well as leading ones in the integer component sounds good as well. I'll do a PR...
PTAL at the commit. I've added a test for this ("tricky precision float") -- NAME are you using the tests?
/me reads above - yes you are, sorry for the noise.
I do not think we should make stripping trailing zeros decimal digits a strict requirement, the number of decimals presented can be out-of-band metadata about the actual precision involved. For instace a timeinterval serialized as 3.0 vs 3.000 vs. 3.000000 might be used to communicate the precision of the measurements as tenths of seconds / milliseconds / microseconds respectively. But we should probably recommend stripping trailing zero decimal digits for bandwidth reasons, if there is no communicative reason to retain them.
If someone wants to use the precision of measurement that way, it'd need to be available in all implementations to be interoperable -- i.e., we'd have to require implementations to preserve that precision. I'm pretty dubious on that being possible and correctly implemented across the board. E.g., requiring every implementation to parse "0.42000" and make the trailing zeros correctly available.
If we're going to round, we probably need to do it before serializing the integer part, since the rounded fractional part may round up to 1.0, as well.
For floats, I think there are two things that we want from this spec (and please let me know if that's not right): Any string which parses as an float can have that float's value stored in a binary64, and serializing that value should reproduce the original string.
Code change:
3.3.2. <del> Floats are decimal numbers with an integer and a fractional component.  The fractional component has at most six digits of precision.  Additionally, like integers, it can have no more than fifteen digits in total, which in some cases further constrains its precision. </del> <ins> Decimals are numbers with an integer and a fractional component.  The Integer component has at most 12 digits; the fractional component has at most three digits. </ins> <del> The ABNF for floats in HTTP headers is: </del> <ins> The ABNF for decimals in HTTP headers is: </ins> <del> For example, a header whose value is defined as a float could look </del> <ins> For example, a header whose value is defined as a decimal could look </ins> like: 3.3.3.

Related discussion:
text: (modulo some number of 0's at either end) Any real value (regardless of storage implementation) in the range -(1e14-0.05) to (1e14-0.05), exclusive, should serialize to its closest valid sh-float representation. (rounding ties towards an even least-significant-digit) Is that reasonable?
Discussed in Singapore: will discuss on list, but sense in the room is to have a fixed point. Hum in the room prefers fixed point. (Need to still determine number of decimals; q-value uses 3).
Specifically pinging NAME NAME NAME for thoughts re: moving float to fixed-point (straw-man: three digits). This seemed to have strong support in the room, but wanted to make sure you're comfortable with it.
Would fixed point be materially different that what is currently specced? Currently, the spec implies a fixed-point with 6 digits of precision, and a maximum of 15 total digits, which (not at all coincidentally) is the same range that is guaranteed to round trip through an IEEE-754 binary64 representation, which is useful for actual implementations. Edit: I see the three-digit difference now; would the integer portion be restricted to 12 digits in that case?
Yes.
I don't have a strong opinion on switching to 12+3 fixed; I think it would cover all of the use cases that I can currently imagine (and I'm trying hard to discount any sunk costs from implementing the previous draft :stuckouttongue:) If implementation complexity (or perceived complexity) factors in to the decision at all, Chrome's current sh-float serializer, which passes the public test suite, is
If people think it's useful to have a fixed-point number, and can settle on the optimal number of digits for most of their use-cases, then
The (only!) two "real" reason we have float/decimal in the first place is values and subsecond resolution time-{intervals,stamps}, and the one "unreal" reason is that JSON offered that. I think has three decimals, either by norm or convention. Time-intervals such as "process-time for this request" are often sub-millisecond, and that has by and large been the argument for "at least six decimals".
Code change:
3.3.2. <del> Floats are decimal numbers with an integer and a fractional component.  The fractional component has at most six digits of precision.  Additionally, like integers, it can have no more than fifteen digits in total, which in some cases further constrains its precision. </del> <ins> Decimals are numbers with an integer and a fractional component.  The Integer component has at most 12 digits; the fractional component has at most three digits. </ins> <del> The ABNF for floats in HTTP headers is: </del> <ins> The ABNF for decimals in HTTP headers is: </ins> <del> For example, a header whose value is defined as a float could look </del> <ins> For example, a header whose value is defined as a decimal could look </ins> like: 3.3.3.

Related discussion:
text: Time-intervals do not convincingly overcome Gettys 1st rule[1] or Phil Karltons rule[2]. so 12.3 would be fine with me. [1] Do not add new functionality unless an implementor cannot complete a real application without it. [2] The only thing worse than generalizing from one example is generalizing from no examples at all.
These days at least, it's by specification. It's a number in the range 0.000 to 1.000, and all algorithms I know of that use it would be just as well served by an integer from 0 to 1000. So the only reason to include the dot is if we want to backport existing headers as-is. Not backporting existing headers was a justification for some decisions earlier on, so if that's been reversed, should we revisit some of those other decisions?
Although thinking more about it, most of the earlier decisions are sort of OBE, so it's maybe not such a big deal.
PTAL