Actually, I and John discussed this issue over Skype last night and John's
response was the result of it. So my comments are included in his response.
BTW, what is the value in normalizing to acct scheme? To me, https seems
perfectly fine, and would not cause the problems that Justin is getting.
=nat via iPhone
Jun 30, 2013 2:17¡¢Mike Jones <Michael.Jones at microsoft.com> ¤Î¥á¥Ã¥»©`¥¸:
Can you work on a concrete proposal to apply as errata, John? And Nat,
once you¡¯re able to think critically, maybe you could work on this as well?
Thanks both,
-- Mike
*From:* John Bradley [mailto:ve7jtb at ve7jtb.com <ve7jtb at ve7jtb.com>]
*Sent:* Saturday, June 29, 2013 9:19 AM
*To:* Mike Jones
*Cc:* Justin Richer; openid-specs-ab at lists.openid.net List; Peter
Saint-Andre
*Subject:* Re: [Openid-specs-ab] Issue #856: Discovery - URI grammar
definition doesn't allow acct: scheme (openid/connect)
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/20130630/3ac22380/attachment.html>