<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: Auth 2.0 Extensions: Namespace Prefixes</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>But it seems superflous: Since you cannot depend on args to<BR>
be ordered[1], you'll still need to iterate and match prefix<BR>
to values.<BR>
<BR>
Also, any change adds complexity: You'll need to specify<BR>
semantics to what happens if the list of extensions is<BR>
not there, or if it is incorrect, or if you use extensions<BR>
without declared namespaces, etc.<BR>
<BR>
But if it still is needed, I'd propose, since the list of<BR>
extensions is meta info, it should itself be an extension.<BR>
<BR>
openid.ns.ext=some:fixed:uri<BR>
openid.ext.namespaces=ns1,ns2,ns3<BR>
openid.ns1.foo=...<BR>
openid.ns1.bar=...<BR>
openid.ns2.foo=...<BR>
<BR>
This makes processing cleaner and it also makes it possible<BR>
for future specification of extensional behavior (sounds<BR>
very Sartre ;)<BR>
<BR>
openid.ext.policy=...<BR>
openid.ext.foo=...<BR>
<BR>
<BR>
-Hans<BR>
<BR>
[1] I'm looking at you HttpServletRequest.getParameterMap()<BR>
<BR>
-----Original Message-----<BR>
From: specs-bounces@openid.net on behalf of Recordon, David<BR>
Sent: Tue 6/5/2007 8:00 AM<BR>
To: Martin Atkins; specs@openid.net<BR>
Subject: RE: Auth 2.0 Extensions: Namespace Prefixes<BR>
<BR>
Since it seems no one has replied yet, I'd agree that this would make<BR>
implementations easier. Iterating via a regular expression seems ugly<BR>
and hard to do (well except in Perl). :-\<BR>
<BR>
--David<BR>
<BR>
-----Original Message-----<BR>
From: specs-bounces@openid.net [<A HREF="mailto:specs-bounces@openid.net">mailto:specs-bounces@openid.net</A>] On<BR>
Behalf Of Martin Atkins<BR>
Sent: Monday, April 30, 2007 12:48 PM<BR>
To: specs@openid.net<BR>
Subject: Auth 2.0 Extensions: Namespace Prefixes<BR>
<BR>
<BR>
As currently defined, an extension has a global namespace URI as well as<BR>
<BR>
a request-local alias/prefix. For an extension with the namespace<BR>
<A HREF="http://example.com/blah">http://example.com/blah</A> that has a field "foo", the following fields are<BR>
<BR>
to be sent:<BR>
<BR>
openid.ns.blah=<A HREF="http://example.com/blah">http://example.com/blah</A><BR>
openid.blah.foo=bar<BR>
<BR>
It seems to me that the only way to discover the extension namespaces<BR>
used in a particular message is to iterate over all keys looking for<BR>
openid.ns.(\w+) and then see if the value matches.<BR>
<BR>
This seems ugly since usually webapps deal with such arguments as a<BR>
dictionary structure, and use dictionary dicipline while interrogating<BR>
the values.<BR>
<BR>
If we added an extra field:<BR>
openid.extensions=blah,sreg,ax<BR>
<BR>
then the extensions used in a message would be accessible by splitting<BR>
that field on its commas and then accessing openid.ns.whatever for each<BR>
one.<BR>
<BR>
It's still not ideal, of course; it'd be better if the full namespace<BR>
URI were included in the "key" part of a (key,value) pair, but many<BR>
frameworks[1] can't deal with wacky punctuation characters in the key.<BR>
<BR>
<BR>
<BR>
<BR>
[1] I'm looking at you, PHP.<BR>
<BR>
_______________________________________________<BR>
specs mailing list<BR>
specs@openid.net<BR>
<A HREF="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</A><BR>
_______________________________________________<BR>
specs mailing list<BR>
specs@openid.net<BR>
<A HREF="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>