OpenID.net Service Type Namespaces

Drummond Reed drummond.reed at cordance.net
Tue Nov 7 19:56:02 UTC 2006


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: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Dick Hardt
Sent: Tuesday, November 07, 2006 8:09 AM
To: Recordon, David
Cc: specs at 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:dick at sxip.com]
> Sent: Saturday, October 21, 2006 7:34 PM
> To: Granqvist, Hans
> Cc: Recordon, David; specs at 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: specs-bounces at openid.net
>>> [mailto:specs-bounces at openid.net] On Behalf Of Recordon, David
>>> Sent: Friday, October 20, 2006 3:09 PM
>>> To: specs at 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 at openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>
>
>

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs




More information about the specs mailing list