OpenID.net Service Type Namespaces

Recordon, David drecordon at verisign.com
Fri Jan 5 08:10:20 UTC 2007


Bringing this back up as now with more extensions I think we need at
least some sort of naming scheme.

I'd propose we use for roots:
http://specs.openid.net/authentication/VERSION...
http://specs.openid.net/extensions/ABBREV/VERSION...

Then corresponding:
http://xmlns.openid.net/extensions/ABBREV/VERSION/...

I'd lean against a date based naming scheme since it means that authors
always need to remember to update for each draft as well as library
developers writing code.

So for OpenID Authentication 2.0, I think this is basically the time to
change it or we leave it forever.  This means for the auth spec we would
have:
http://specs.openid.net/authentication/2.0/signon
http://specs.openid.net/authentication/2.0/server
http://specs.openid.net/authentication/2.0/identifier_select

So very verbose and organized.  There is no need for an xmlns for the
Auth 2.0 spec itself, since unlike the 1.1 spec which defined
"OpenID:Delegate" in Yadis, 2.0 takes advantage of the "LocalID" element
already defined in the XRD schema.

I'm obviously +1 for this naming scheme, want to get it right even
though we are beyond the eleventh hour.

--David

-----Original Message-----
From: Dick Hardt [mailto:dick at sxip.com] 
Sent: Tuesday, November 07, 2006 1:07 PM
To: Recordon, David
Cc: Drummond Reed; specs at openid.net
Subject: Re: OpenID.net Service Type Namespaces

I get the hostname aspect for another namespace.

w3c[1] uses:

	http://www.w3.org/ns/sss
	http://www.w3.org/YYYY/MM/ssss

I have no strong opinion on it though

[1] http://www.w3.org/2005/07/13-nsuri

On 7-Nov-06, at 12:07 PM, Recordon, David wrote:

> 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
>
>
>





More information about the specs mailing list