My understanding is that the concern is with potential conflicts in the actual functioning of openid.net.
Creating a clean DNS namespace for specs at specs.openid.net does seem like a good solution to me. =Drummond -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, November 07, 2006 8:09 AM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID.net Service Type Namespaces What is the concern? The argument for keeping it the current way is for consistency. The URL resolution does not need to be trusted does it? On 6-Nov-06, at 5:04 PM, Recordon, David wrote: > I'm still concerned with using the "openid.net/" namespace. > Objections > to using http://specs.openid.net/authentication/2.0/signon? We don't > need to change this in legacy stuff, just for 2.0 moving forward. > > --David > > -----Original Message----- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 21, 2006 7:34 PM > To: Granqvist, Hans > Cc: Recordon, David; specs@openid.net > Subject: Re: OpenID.net Service Type Namespaces > > I am very supportive of an HTTP GET retrieving the specification. > > I think there are some issues with putting the date in the URL: > > 1) the URL is unknown until the spec is completed. Any implementations > being done during the specification then have a moving target. The URL > is embedded in the Yadis document and I can see it causing some > headaches for people that it is not fixed until the end. > > 2) the grouping is by time instead of by specification. If I want > to see > all versions of a specification, it is not obvious > > Currently we have: > http://openid.net/signon/1.0 > http://openid.net/signon/1.1 > http://openid.net/server/2.0 > http://openid.net/signon/2.0 > http://openid.net/identifier_select/2.0 > > Given that the 1.x ones are already there, I would recommend we keep > using that scheme. > > -- Dick > > On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote: > >> It has had some voices against it, but how about considering this >> template (used in for example W3C xmldsig and >> xmlenc): >> >> http://openid.net/[year]/[month]/[project]#[type] >> >> Time-dependent (rather than version--dependent) namespaces can evolve >> freely and will not be tied down to specific versioning numbers. >> >> Example: >> http://openid.net/2006/10/authentication >> http://openid.net/2006/10/authentication#signon >> >> >> It's cool if an HTTP GET on these links returns the specification. >> >> Once a spec is finalized, the then current year/month becomes that >> spec's namespace. For example, xmlenc's namespace is >> http://www.w3.org/2001/04/xmlenc >> >> Hans >> >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David >>> Sent: Friday, October 20, 2006 3:09 PM >>> To: specs@openid.net >>> Subject: OpenID.net Service Type Namespaces >>> >>> Right now we have things like http://openid.net/signon/1.1, >>> http://openid.net/sreg/1.0, etc. This doesn't really seem to scale, >>> populating the main http://openid.net namespace. >>> >>> Could we do something like >>> http://specs.openid.net/authentication/2.0/signon or >>> http://specs.openid.net/authentication/2.0/identifier_select >>> as well as then http://specs.openid.net/sreg/1.0? >>> >>> This would give all the specs their own namespaces, as well as make >>> it so we can do smart redirection from each of these "type" urls to >>> the correct anchor in the individual spec. >>> >>> --David >>> _______________________________________________ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs >>> >>> >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> > > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
