Re: Request for feedback on draft-go-protocol (shortlink resolution)

 Um, who needs this?  What for?  I see fewer and fewer shortlinks these
days.

For some years while working at Google and AWS I used “Design TinyURL in a
way that is highly scalable and produces as-short-as-possible output” as a
senior software person interview question. I ended up having my ideas about
how to do this completely changed by listening to smart people think about
the problem.  -Tim

On Nov 2, 2025 at 1:31:54 PM, Ethan Davidson <ethan.r.davidson@gmail.com>
wrote:

>
>
> ---------- Forwarded message ---------
> From: Ethan Davidson <ethan.r.davidson@gmail.com>
> Date: Sun, Nov 2, 2025 at 1:27 PM
> Subject: Request for feedback on draft-go-protocol (shortlink resolution)
> To: <http-wg@ietf.org>
> Cc: mnot@mnot.net <mnot@mnot.net>, <tpauly@apple.com>
>
>
> Hello http-wg,
>
> I'm Ethan Davidson, and I'd like to introduce a new Internet-Draft that
> I've submitted. This is not only a new draft, but also my first
> Internet-Draft.
>
> The Problem:
>
> Implementations resolve shortlinks inconsistently, especially with query
> parameters and internal redirects. Without a standardized resolution
> algorithm, different implementations may resolve the same shortlink to
> different destinations or handle edge cases inconsistently, leading to
> interoperability issues.
>
> A key motivation for this draft is the quality of life improvement it
> provides: with this standardized algorithm, organizations can define their
> entire shortlink configuration as a simple Record<string, string> (or
> equivalent key-value representation), making shortlink management
> straightforward and portable across different implementations, languages,
> and platforms.
>
> The Draft:
>
> I've submitted draft-go-protocol-00, "A Deterministic Algorithm for
> Resolving Shortlinks with Internal Redirects," which can be found at:
> https://datatracker.ietf.org/doc/draft-go-protocol/
>
> The Solution:
>
> This draft specifies a deterministic algorithm for resolving shortlinks
> that supports longest-prefix key matching to enable hierarchical shortlink
> structures, handles both absolute URL destinations and origin-relative
> internal redirects, provides loop protection for internal redirect chains
> (limited to 256 iterations), and defines clear precedence rules for
> combining query parameters and fragments from multiple sources. The
> algorithm is designed to remain stateless and deterministic for consistent
> behavior across implementations, working with any ruleset source (database,
> file, configuration, etc.) without requiring protocol-level changes or IANA
> registrations.
>
> Request for Feedback:
>
> I would greatly appreciate any review and comments on this draft. In
> particular, I'm interested in feedback on:
> - The longest-prefix matching algorithm and its behavior
> - The query parameter and fragment precedence rules
> - The loop protection mechanism and determine what is an appropriate limit
> - Any edge cases or security considerations I may have overlooked
>
> I've also set up a GitHub repository for tracking issues and detailed,
> line-by-line feedback, which can be found at:
> https://github.com/EthanThatOneKid/go-protocol/issues/
>
> Thank you for your consideration, and I look forward to your feedback.
>
> Best regards,
> Ethan Davidson
> https://etok.me/
>