Re: [art] Putting actual credentials in URIs was an accident of history, let's repurpose those fields instead?

"Soni L." <fakedme+art@gmail.com> Tue, 28 February 2023 11:47 UTC

MIME-Version: 1.0
References: <9568aaa5-21f3-a40c-92ed-57d8b217813f@gmail.com> <87D11F6BD1CB162884B065D5@PSB>
In-Reply-To: <87D11F6BD1CB162884B065D5@PSB>
From: "Soni L." <fakedme+art@gmail.com>
Date: Tue, 28 Feb 2023 08:46:54 -0300
Message-ID: <CA+-cKyN-EBNj21AA3Yx5N_Hmuz2QTnB0oRdPmgM2AwTvrnyruQ@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: art@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a95b3505f5c1277d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/WoVapOs2hpx9luhBsDKPzJg-ccw>
Subject: Re: [art] Putting actual credentials in URIs was an accident of history, let's repurpose those fields instead?
Precedence: list

Okay... How about renaming "username@" to "servicetag@"? This would make a
good excuse to stop the WHATWG from swallowing the "git@" part of "ssh://
git@github.com" and is entirely backwards-compatible, and it also better
aligns with how these things get used in public APIs anyway (case in point:
how github uses it).

(This is, in fact, the whole motivation for doing something cursed like
attempting to repurpose these: simply having the WHATWG stop swallowing the
actually very important "username" tag.)

On Tue, Feb 28, 2023, 00:32 John C Klensin <john-ietf@jck.com> wrote:

> Soni,
>
> With the caveat that I'm still not convinced that sub-schemes
> are a good idea and noting that I can find nothing in either RFC
> 3986 or BCP35 that gives "+" any special status (e.g., there is
> no more inherent relationship between web+git: and web+xyz: than
> there is between the former and a hypothetical "example:"
> scheme), the idea of "repurposing" a some syntax so that a
> construction that once meant one thing would henceforth mean
> something else is, for lack of a better term, creepy. An obvious
> problem is that, regardless of what contemporary web browsers
> and servers do, there are devices around with embedded HTTP
> servers and URL processors that date from the mid-1990s.  Might
> some of them still be around and dependent on the old
> interpretation of the syntax?  It would be really hard to prove
> otherwise but, unless one could do so, to "repurpose" those
> fields would be an attack on the IETF's obligations about
> stability and interoperability.  Might be worth doing anyway if
> it were clear that the functionality was critical _and_ there
> were no plausible alternatives, but it seems to me that Dale
> Worley's note [1] provides both a good analysis and a collection
> of plausible alternatives.
>
> So let's not go there.
>
>    john
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/art/A6PXgEvhZ50JHViQgWntdCxzg9U
>
> --On Friday, February 24, 2023 12:42 -0300 "Soni L."
> <fakedme+art@gmail.com> wrote:
>
> > So how bad of an idea would it be to repurpose "username" and
> > "password" in URIs for all sorts of stuff? E.g.
> > https://soniex2.tumblr.com/post/705832532473724928/so-heres-ou
> > r-plan-we-wanna-have-web-git-urls
> >
> > ---
> >
> > so here's our plan: we wanna have web+git URLs, and it
> > should look like web+git://username:namespace@hostname/path
> >
> > so for example, on something like github, username = the
> > username of the owner of the repo, namespace = always empty
> > since github doesn't support namespaces, hostname =
> > github.com, path = repo name.
> >
> > on something like bitbucket, which does support namespaces,
> > the namespace can be non-empty.
> >
> > on something more selfhosted, the username and namespace could
> > be omitted entirely.
> >
> > e.g. we could have
> > web+git://fedi-to@github.com/fedi-to.github.io
> >
> > e.g. we could have web+git://soniex2.autistic.space/dfu
> >
> > how cursed is this?
>
>
>

[art] Putting actual credentials in URIs was an a… Soni L.
Re: [art] Putting actual credentials in URIs was … worley
Re: [art] Putting actual credentials in URIs was … John C Klensin
Re: [art] Putting actual credentials in URIs was … Soni L.