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

[John Bradley <[e-mail]>]

> 1) say the parameter takes "any URI or user@host"

Also move acct: tp a different spec.  If it gets approved that's fine.  If people use an un-appoved scheme name as an identifier for computability with existing deployments that is fine as well, but it should not be in the WF spec.

I think Blane and I agree on the point that the server not the client is in the best position to figure out what the user intended if they type in [e-mail].   The client is adding acct: to say that it doesn't know.  sending a relative URI as we do in SWD and letting the server figure it out is probably the best thing.

It is a parameter, I don't see any reason that a relative URI would not be valid, as long as a authority is present.

John B.


On 2012-05-25, at 7:06 AM, Michiel de Jong wrote:

> 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?