@movq@www.uninformativ.de I reckon section numbers are not really needed for articles. But if you number them, the anchors should probably not contain the section number, just the title. Especially for articles that may receive updates.

It’s probably another story for specifications. They’re kinda fixed and thus I found it useful in the past to include the section numbers in the anchors, so they show up in URLs when linking to specific sections. W3C RFCs only include the numbering in the anchors. This makes URLs fairly short, but it would be also nice to directly see what kind of section that URL actually links to.

@movq@www.uninformativ.de Yeah, that would also be fine with me. I certainly do like the “arbitrary” in your comment.

While writing the article, I also thought about something like that:

date := time.Date(2026, 6, 19,
    17, 0, 0, 0, time.UTC)

Or possibly:

date := time.Date(
    2026, 6, 19,
    17, 0, 0, 0, time.UTC,
)

But it’s four lines for a damn timestamp. I also contemplated whether a comment acting as a separator is all that’s needed:

date := time.Date(2026, 6, 19, /**/ 17, 0, 0, 0, time.UTC)

I might like that the most. Not entirely sure yet. It kinda feels like a hack, but still a little elegant. Add your comment on top and we’re golden. Maybe?

I deliberately excluded them as this only distracted from the points I wanted to make. And I also realized that this example was just not ideal at all. Perhaps I should add them nevertheless?

If I ever invented a programming language, a much more human readable timestamp representation of some sort, RFC 3339 or very close to that would be part of that language. Something along the lines of /pattern/ for regexes in certain languages.

@movq@www.uninformativ.de Great to be asked for feedback! I just noticed that the first wcwidth version was derived from Markus Kuhn’s C code. I came across him in my ISO 8601 and RFC 3339 endeavors the other day. https://www.cl.cam.ac.uk/~mgk25/iso-time.html What a surprise. :-)

Aha, yesterday’s newly added support for LC_TIME to render localized timestamps also broke the feed parsing with my LANG=de_DE.UTF-8 and LC_CTYPE=de_DE.UTF-8 environment. :-)

Atom feeds make use of RFC 3339 timestamps. They are first converted into RFC 882 timestamp representation, which is the one that RSS feeds use. However, this conversion now results in localized RFC 882 timestamps, which cannot be parsed into Unix timestamp numbers via curl_getdate(…). I bet that it doesn’t know about the localization at all and expects English month and weekday names. Looking at its docs, I reckon that function was selected because of its myriad of supported timestamp formats: https://curl.se/libcurl/c/curl_getdate.html RFC 3339 is not included, though, hence the transformation up front.

The intermediate Item objects in the parser domain use std::string for the timestamp representation. This isn’t all that silly, because Newsboat supports all sorts of different feed formats with different timestamp formats. These RFC 883 timestamps are centrally parsed into time_t.

Speaking of time: It’s time to go to bed after this late bug hunting fun. :-)

I kind of hate conventional commit messages: https://www.conventionalcommits.org/en/v1.0.0/#summary

but I am loving reading RFC 2119: https://www.ietf.org/rfc/rfc2119.txt

All my newly added test cases failed, that movq thankfully provided in https://git.mills.io/yarnsocial/twtxt.dev/pulls/28#issuecomment-20801 for the draft of the twt hash v2 extension. The first error was easy to see in the diff. The hashes were way too long. You’ve already guessed it, I had cut the hash from the twelfth character towards the end instead of taking the first twelve characters: hash[12:] instead of hash[:12].

After fixing this rookie mistake, the tests still all failed. Hmmm. Did I still cut the wrong twelve characters? :-? I even checked the Go reference implementation in the document itself. But it read basically the same as mine. Strange, what the heck is going on here?

Turns out that my vim replacements to transform the Python code into Go code butchered all the URLs. ;-) The order of operations matters. I first replaced the equals with colons for the subtest struct fields and then wanted to transform the RFC 3339 timestamp strings to time.Date(…) calls. So, I replaced the colons in the time with commas and spaces. Hence, my URLs then also all read https, //example.com/twtxt.txt.

But that was it. All test green. \o/

Nobody writes emails by hand using RFC 5322 anymore, nor do we manually send them through telnet and SMTP commands. The days of crafting emails in raw format and dialing into servers are long gone. Modern email clients and services handle it all seamlessly in the background, making email easier than ever to send and receive—without needing to understand the protocols or formats behind it! #Email #SMTP #RFC #Automation

thanks @prologic!
@bender the idea of the RFC was to reach an agreement on a difficult problem, receiving proposals, and the voting is a simple count to gauge the sentiment of “is this a problem worth to be fixed?, are we committed to implement a change in our clients?”

But that’s a fair point. What do the community expect? What do y’all expect?

TIL that RFC means Request For Comments

Hi everyone,
I’ve drafted a Request for Comments (RFC) to improve how threads work in twtxt:
https://git.mills.io/yarnsocial/twtxt.dev/issues/18

I’d love your feedback! Please share your thoughts on anything that could be better explained, check if the proposed dates work for everyone, and I invite you to join the discussion…

i always thought that i needed geodns to make a multi-region setup work at all, but it turns out all we really need is one rfc https://datatracker.ietf.org/doc/html/rfc8305 and its not even rare to see implemented on clients

@lyse@lyse.isobeef.org agree on the HTTP stuff. I mean we could mention that for optimization see RFC yadda yadda should be followed for caching. but not have it part of the spec proper.

Aujourd’hui, petits changements de formatage de mes documents sur le style RFC. Le titre apparaît désormais au centre et en haut de page. On a aussi la date de rédaction suivie de la date de dernière mise à jour. Que c’est beau :)

Note pour plus tard : se documenter sur les ADR architectural décision records. En complément des RFC, élaboration collaborative, l’ADR trace les décisions.

Line Length Limits “SHOULD be no more than 78 characters, excluding the CRLF” https://www.ietf.org/rfc/rfc2822.txt

@prologic@twtxt.net Unfortunately the RFC’s are a bit light in this regard. While it makes mention of different kinds of accounts like mailto: or status services.. it never combines them. It does make mention of using redirects to forward a request to other webfingers to provide additional detail.

I am kinda partial to using salty:acct:me@sour.is, yarn:acct:xuu@txt.sour.is, mailto:me@sour.is that could redirect to a specific service. and a parent account acct:me@sour.is that would reference them in some way. either in properties or aliases.

@bml@twtxt.net Yup, several. My favorite is RFC 1149, another that’s since been implemented. https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments

interesting RFC dated April 1st, 1998: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0):

https://tools.ietf.org/html/rfc2324

looking at the date this was published, i think the authors originally meant this as an apil’s fool joke/prank.

funny because now we have IOTs and this is somewhat a reality today :P

@xuu@txt.sour.is Not too happy with WKD’s use of CNAME over SRV for discovery of openpgpkey.. That breaks using SNI pretty quick. I suppose it was setup as a temporary workaround anyhow in the RFC..