Yes, “URL” is strongly and clearly deprecated in RFC3986 section 1.1.3; one of the reasons is that the distinction between “locator” and “identifier” which sounds like it should be easy, turns out to lead to theological bikeshed discussions almost inevitably, and in fact be shaky in practice. -T
On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones <michael.jo...@microsoft.com>wrote: > Tim, as background, this came from the OpenID Connect specs, where we > tried to consistently use the convention that the locator for any resource > that can be retrieved from the specified location be called a URL, whereas > any identifier that may not be retrievable is called a URI. That was done > as an aid to developer understanding of the specifications.**** > > ** ** > > If the use of “URL” is deprecated by the IETF in favor of always just > using “URI”, I suppose we could change that, but if it’s going to change, > it should be soon.**** > > ** ** > > -- Mike**** > > ** ** > > ** ** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Nat Sakimura > *Sent:* Wednesday, February 20, 2013 8:57 AM > *To:* Tim Bray > *Cc:* <oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt**** > > ** ** > > You are right. I am in the camp recommending the use of URL when it is a > concrete endpoint and URI when it includes something that is only abstract, > but since OAuth standardized on "uri", we may as well do so here. **** > > ** ** > > Nat**** > > 2013/2/20 Tim Bray <twb...@google.com>**** > > In OAuth, we have redirect_uri not redirect_url; should this be > registration_access_uri for consistency? -T**** > > ** ** > > On Wed, Feb 20, 2013 at 8:23 AM, John Bradley <ve7...@ve7jtb.com> wrote:** > ** > > I think registration_access_url is OK. I haven't heard any better names > yet.**** > > ** ** > > John B.**** > > ** ** > > On 2013-02-20, at 1:04 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > **** > > > > **** > > For what it’s worth, the name “registration_access_url” was chosen to be > parallel to “registration_access_token”. It’s the place you use the > access token. And it’s where you access an existing registration. I’m > against the name “client_metadata_url” because it’s not metadata you’re > accessing – it’s a registration you’re accessing. For the same reason, I > don’t think the name “client_info_url” gives people the right idea, because > it doesn’t say anything it being the registration that you’re accessing.** > ** > > **** > > If you really want us to change this, having read what’s above, I could > live with “client_registration_url”, but I don’t think a change is actually > necessary. (But if we are going to change it, let’s do it ASAP, before the > OpenID Connect Implementer’s Drafts are published.)**** > > **** > > -- Mike**** > > **** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Nat Sakimura > *Sent:* Wednesday, February 20, 2013 7:58 AM > *To:* <oauth@ietf.org>; Richer, Justin P.; John Bradley > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt**** > > **** > > Thanks Justin. > > Even if we go flat rather than doing JSON Structure, the "Client > Registration Access Endpoint" is not a good representative name. > > What it represents is the client metadata/info. > It is not representing "Client Registration Access". **** > > What does "Client Registration Access" mean? **** > > Does UPDATing "Cleint Registration Access" make sense? > > Something in the line of "Client Metadata Endpoint" and > something like "client_metadata_url" or "client_info_url" is much better. > > Nat**** > > 2013/2/15 Richer, Justin P. <jric...@mitre.org>**** > > Everyone, there's a new draft of DynReg up on the tracker. This draft > tries to codify the discussions so far from this week into something we can > all read. There are still plenty of open discussion points and items up for > debate. Please read through this latest draft and see what's changed and > help assure that it properly captures the conversations. If you have any > inputs for the marked [[ Editor's Note ]] sections, please send them to the > list by next Thursday to give me opportunity to get any necessary changes > in by the cutoff date of Monday the 22nd. > > Thanks for all of your hard work everyone, I think this is *really* coming > along now. > > -- Justin**** > > > On Feb 15, 2013, at 4:54 PM, internet-dra...@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol Working > Group of the IETF. > > > > Title : OAuth Dynamic Client Registration Protocol > > Author(s) : Justin Richer > > John Bradley > > Michael B. Jones > > Maciej Machulak > > Filename : draft-ietf-oauth-dyn-reg-06.txt > > Pages : 21 > > Date : 2013-02-15 > > > > Abstract: > > This specification defines an endpoint and protocol for dynamic > > registration of OAuth Clients at an Authorization Server. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > > > **** > > **** > > -- > Nat Sakimura (=nat)**** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > > ** ** > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > ** ** > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > > > **** > > ** ** > > -- > Nat Sakimura (=nat)**** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
