[Openid-specs-ab] Issue #856: Discovery - URI grammar definition doesn't allow acct: scheme (openid/connect)

[Tim Bray]

Another way to address this issue would be to just forget about the "acct"
scheme, which adds no value that I can think of and  bulks up the webfinger
spec unnecessarily.  -T


On Sat, Jun 29, 2013 at 9:18 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> I think part of our problem is that in RFC3986 "host" is part of authority
> and authority is part of higher-part which begins with "//".
>
> The "mailto" scheme stuffs everything into path so doesn't have and
> authority owing to dealing with multiple recipients (it is a complex
> scheme) .
>
> If "acct" was using higher-part rather than path it would simplify our job
> trying to normalize the various sorts of inputs for discovery.
>
> The "acct" scheme uses  ":"  userpart "@" host  (It defines userpart
> rather than re using userinfo).  While being unusual having host in a path,
> I am guessing it is just the ABNF, so is a different host from the one in
> higher-part.
>
> I don't think the below works for generic URI without a higher-part so we
> would be better  saying  or "acct" ":" userpart "@" host.
>
> That leaves out the mailto uri but processing rules to generically pick
> that apart are a real challenge, and would need to be restricted to a
> single recipient with no headers etc so would need it's own section for
> that scheme specifically if we want to support it.
>
> There is also a problem with differentiating foo.org:8080 as that could
> be interpreted as a scheme or foo.org with a path of 8080 so being
> explicit about what schemes without higher-part are supported may be a good
> idea.
>
> John B.
>
> On 2013-06-29, at 7:20 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>
> I'd add another "or" to prevent confusion as below, but otherwise I agree
> with this change.  Do others?****
> ** **
> a URI in the form of scheme "://" authority path-abempty [ "?" query ] [
> "#" fragment ] or authority path-abempty [ "?" query ] [ "#" fragment ] or
> scheme ":" userinfo "@" host per RFC 3986 [RFC3986]****
> ** **
>
> -- Mike****
> ** **
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-
> specs-ab-bounces at lists.openid.net] On Behalf Of Justin Richer
> Sent: Friday, June 28, 2013 6:55 AM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Issue #856: Discovery - URI grammar definition
> doesn't allow acct: scheme (openid/connect)
> ** **
> New issue 856: Discovery - URI grammar definition doesn't allow acct:
> scheme
> https://bitbucket.org/openid/connect/issue/856/discovery-uri-grammar-definition-doesnt
> ****
> ** **
> Justin Richer:****
> ** **
> The instructions as written in 2.1.1/2.1.2 don't actually allow for the
> acct: URI scheme. The acct: scheme is a non-heirarchical URI, which means
> it doesn't include the "//" component, and the text currently states:****
> ** **
> ```****
>     a URI either in the form of scheme "://" authority path-abempty [ "?"
> query ] [ "#" fragment ] or authority path-abempty [ "?" query ] [ "#"
> fragment ] per RFC 3986 [RFC3986].****
> ```****
> ** **
> I think this needs an errata published as the intent was more like:****
> ** **
> ```****
>     a URI in the form of scheme "://" authority path-abempty [ "?" query ]
> [ "#" fragment ], authority path-abempty [ "?" query ] [ "#" fragment ],
> **or scheme ":" userinfo "@" host** per RFC 3986 [RFC3986].****
> ```****
> ** **
> ** **
> ** **
> ** **
> _______________________________________________****
> Openid-specs-ab mailing list****
> Openid-specs-ab at lists.openid.net****
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130629/5008bbb1/attachment.html>