Revert adoption of httpwg.org URLs

[dontcallmedom]

https://github.com/tobie/specref/pull/539 added a hardcoded map from a number of RFCs to their (much more nicely rendered) equivalent in httpwg.org space, but without much discussion or background.

While the improved rendering is certainly valuable, I'm not sure if using a WG-specific domain without clear institutional backing is necessarily the right thing to do by default for links that may end up encoded in formally approved standards.

It's also impacting our browser-specs tool which consumes data from specref to collect metadata about specifications, as we're considering adding some of these RFCs to our list; we can easily override this on our end, but since the validity of the specref data was at least not obvious to us, we thought we would bring this up for discussion here first.

cc @tidoust @mnot

[dontcallmedom]

@tobie any thoughts on this?

[tobie]

I was waiting for @mnot to weigh in.

[mnot]

without clear institutional backing

I guess it depends on what you mean by this. The IETF doesn't really do "official" URLs like the W3C does; the most relevant ones are probably the rfc-editor.org ones, but even they don't have an explicit persistence policy.

It also depends on what you consider to be the relevant institution - is it the IETF, the RFC Editor, or the HTTP WG?

All of that said - I don't have very strong feelings here. We put the specs up on httpwg.org because a) we wanted all of the relevant ones in a single place, since discovery in the RFC series sucks, and b) we wanted them to be easier on the eyes.

[dontcallmedom]

given that specref describes these specs with their publisher being IETF, it feels like IETF is the relevant institution in this context - I've filed #675 to proceed with reverting to datatracker.ietf.org URLs.

[tobie]

What if we treated those as editor's drafts instead? Feels like a reasonable-ish compromise?

[dontcallmedom]

I thought about this, but this wouldn't quite right - there are actual editors drafts with different / more up-to-date content, e.g. https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html.

[dontcallmedom]

let me rephrase - I wouldn't object at all to that compromise, but if we do, I want to make sure we understand that implication

[marcoscaceres]

@tobie, is it ok if we proceed with #675? Otherwise we will have to patch this upstream in different projects.

[tobie]

This seems to favor formalism over usability, which I find at odd with some of our guiding principles. I feel like this warrants a deeper conversation. I’m also ooo at the moment and so don’t really want to spend energy defending this point of view right now. I would have preferred a more nuanced solution.

[dontcallmedom]

thanks for taking the time to reply during your time off :)

taking more time to discuss the trade-off makes sense; I'll deal with it downstream for the time being

[tobie]

Thanks for your understanding. I hope this isn’t creating excessive downstream work.

[dontcallmedom]

noting an additional dimension here from the browser-specs discussion: recent RFC are published using a more modern format on rfc-editor.org - so maybe that would be a better default than datatracker ones (for non httpwg.org urls in this case).

[dontcallmedom]

submitted #675 re rfc-editor.org URLs.

I'm no longer convinced that reverting the use of httpwg.org is the right approach (per the priorities of the constituencies as @tobie pointed out), so closing this issue.