On the FOSS server fossies.org I have used a new functionality and have done as a trial a "codespell" run for the "lsquic" project. Here the version independent URL of the resulting report:

https://fossies.org/linux/www/lsquic/codespell.html

That URL redirects always to the URL of the report for the last "lsquic" release supported on Fossies (in case such a report was requested respectively

I've already retrieved some WHOIS records and stashed them in a file. Now I want to parse them (without retrieving them again).

Is there a way to access the WHOIS parser via the ipwhois API?

Bibliography is stored in a map and when we range over it we get the elements in random order; this should be sorted so a single source markdown file always maps to the same output.

Per mikewest:

No, cross-site frames should not be able to access SameSite=AnythingButNone cookies via document.cookie. The spec doesn't make this clear (you have to read between the lines of bullet 5 of step 1 of https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-06#section-5.5), so we should change the spec.

Would be awesome if someone could include some of the new draft-7 features into the examples. E.g. I'm highly interested in the actual use of if / then / else but can't find any examples.

Both caching and semantics make some references to h1-messaging. They should not be normative.

We can do this by:

• Removing unnecessary references
• Turning references into examples / advisory text
• Clarifying H1 specificity where appropriate

Includes #332, #333, #311, #259, #183, #182, #118.

The official and locally built napalm-logs Docker container I made don't support the kafka transport. Upon inspection, I realized that kafka-python is missing from requirements.txt--so it will never make it into the container. I've fixed this in my fork, but wanted to know if that was deliberately left out or if there's a way to get it into the Docker container other than this that I'm not aware o

I've changed my local version to:

public QuicStreamContext CreateStream(ulong streamId = 1, StreamType streamType = StreamType.ClientBidirectional);

in order to keep the compatibility.

See today's thread on gen-art about this.

The answer to:

Why aren't per-directory well-known locations defined?

Given in Appendix A could be moved into Section 3.

  Allowing every URI path segment to have a well-known location
  (e.g., "/images/.well-known/") would increase the risks of

https://github.com/martinthomson/i-d-template/blob/master/v3.css selects the "Cabin Condensed" font for section titles. I find the narrow letters hard to read and would prefer a normal width font instead.

SNI is currently mentioned in the Manageability document, but you'd have to read a substantial chunk of the transport and tls drafts to understand how to extract it.

I'd suggest a short section that describes how it's presented on the wire with references to the appropriate sections on transport and tls.

Currently, the section on client Initial says: "The Client Hello datagram exposes versio

RFC8392 doesn't say whether the URI tag #6.32 should or should not be used on the issuer, subject and audience claims. Without it the decoder would use a URI syntax matcher to decide between it being text or a URI.