Field separators, again

[Brad Fitzpatrick]

On Wed, 8 Jun 2005, Paul Crowley wrote:

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

I don't get that part.  How is this content-type issue related to the
what-are-we-signing issue?  Please don't merge them as one issue.  Don't
lock us into one serialization format.

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

And it might be ZERO code if their environment treats XML as a first class
type, as more and more do.

As for server-side "overkill", you don't need XML libraries on the server
to generate XML... you just print out:

<openidResponse>
  <param name='openid.mode'>id_res</param>
  <param name='openid.mode'>id_res</param>
  <param name='openid.mode'>id_res</param>
</openidResponse>

I think that's easy for any server to do, provided the XML fans in the
audience can tell us what schema they'd like.

Then they say:

openid.response_type=text
Or:
openid.response_type=xml

Then we leave it to consumers to decide which they want to parse.

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

I think that obfuscated one-liners don't help win arguments in favor of
simplicity of parsing.  :-)

In the end, I don't care much about this issue, but I don't want to fight
over it for long.... which is why I favor the consumer-decides approach.

- Brad