Re: [apps-discuss] The acct: scheme question

[Michiel de Jong <[e-mail]>]

On Thu, May 24, 2012 at 2:27 PM, John Bradley <[e-mail]> wrote:
> Until acct: is an approved URI I am not keen to have openID Connect take a normative reference to it.

Indeed I think we can conclude:
- an acct: scheme would be helpful
- it does not currently exist
- we have to think about what to do until it exists

On Wed, May 16, 2012 at 4:34 PM, Blaine Cook <[e-mail]> wrote:
> I'm completely and totally opposed to webfinger not accepting
> scheme-less addresses.
>
> Please start from the user experience – no-one in the history of the
> internet has typed "http://" into a browser window address bar (I may
> be overstating that, but statistically speaking it's true).
>
> Likewise, no-one will ever type "acct" or "mailto" or "xmpp" or
> anything else into a form field.
>
> To require clients to convert "[e-mail]" into
> "acct:[e-mail]" is just pedantry of the worst sort. If I had it
> my way, webfinger (not host-meta) wouldn't even resolve URIs; it would
> only resolve scheme-less email identifiers, because that's what we're
> doing.
>
> I *understand* that there *should* be an URI for these things;
> however, there is prior art for not having an URI – DNS is a core
> piece of internet infrastructure that uses "bare" identifiers all the
> time precisely to find *resolvable* resources that *do* use URIs.
>
> I'm not going to stand in the way of consensus, but if the IETF
> specification ends up stating that bare identifiers are not supported,
> then I will personally consider this work a failure as I believe
> strongly enough that URIs are not necessarily appropriate here. :-/
>
> b.

And this was +1'ed by Mike Jones. So I pointed out that:


Once acct: is a URI scheme, you'll be able to say the parameter takes
"any URI". Until then, you'll have two options:

1) say the parameter takes "any URI or user@host"
2) say the parameter takes "any existing URI scheme or acct:user@host"

I think we agree that as Blaine said, there *should* be an URI, but I
think we also can agree that the limbo period would be too long to say
"let's first wait to see if acct: gets accepted, and then decide what
we do". So we have to make a choice about the period between now and
the 'verdict'. For that period, I would vote for option 1. I think
it's clear that option 1 has a down-side:
- it deviates from host-meta as such

but option 2 has three downsides:
- in relying on a scheme that does not *yet* exist, it also deviates
from host-meta, so that doesn't change
- it could lead to rejection-domino, should acct: get rejected
- it involves dropping bare user addresses, and Blaine already said
he's "completely and utterly" opposed to that.

I'm in favour of option 1, and from what i read, some more people are.
Some other people have stated they are simply not interested in making
the scheme-less case work, which is fair enough. I don't think anybody
is in favour of suspending production use until we get an answer about
the proposed URI scheme, although I might be wrong. There are probably
some other positions which i'm underrepresenting here, sorry if that's
the case.

But when phrased this way, is anybody in favour of option 2?