OpenID.net Service Type Namespaces

[Recordon, David]

Yeah, that is my concern.  Much easier to manage the namespace if this
part is separate, then no matter what software is run for openid.net
anytime down the road we won't have issues.

--David 

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed at cordance.net] 
Sent: Tuesday, November 07, 2006 11:56 AM
To: 'Dick Hardt'; Recordon, David
Cc: specs at openid.net
Subject: RE: OpenID.net Service Type Namespaces

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