Field separators, again

[Paul Crowley]

The draft spec currently says that x-www-form-urlencoded is used to 
encode the replies to get_authkey requests.  However, it's easy to 
imagine that for some consumers this could be a bind.  The environment 
they run in may not give them easy direct access to a parser for this 
format - it may have to be part of a GET request.

Rolling your own parser for this is a bit of a pain, too - you have to 
handle percent-escapes.

Would it be simpler to go for something like this?

dh.gy:NgYl16...gns4rBV43z0DSSzhU=
auth_type:hmac-sha1
enc:dh
enc_secret:tOQCAxR...1BndtvQH=
secret_handle:382342/98723742
secret_expiry:2005-06-03T12:00:00
server_time:2005-06-03T00:13:03

We're not expecting newlines in the output, and pretty much everything 
can make a decent fist of parsing line-oriented output.

The nice thing about this is that we can also use it for our token 
format, replacing the rather ugly and unreadable

assert_identity
valid_from,valid_to,is_identity,return_to
2005-06-07T22:31:05
2005-06-07T23:31:05
http://ciphergoth.livejournal.com/
http://www.bloghost.com/return-to-me-openid

with the far more debuggable

mode:id_res
valid_from:2005-06-07T22:31:05
valid_to:2005-06-07T23:31:05
is_identity:http://ciphergoth.livejournal.com/
return_to:http://www.bloghost.com/return-to-me-openid

(using mode:id_res to do the job of assert_identity in the other format)

How does that seem?

Brad suggests that servers can provide more than one format, on the 
assumption that servers are smart but consumers are dumb, so servers 
should provide whatever consumers will find most convenient.  One thing 
some consumers might prefer, for example, would be XML.  I think that's 
overkill for now; everyone should be able to parse the format here with 
hardly any code.  In Python, for example, you can do it with

dict([(lambda x, y: (x, y.rstrip()))(*l.split(':',1)) for l in f])

What do other poeple think?
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.or