Field separators, again

[Paul Crowley]

Brad Fitzpatrick wrote:
> 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.

OK.  I didn't want to have more serialization formats floating about 
than were strictly necessary, just because it makes the standard longer. 
   I think the format I suggest is better for the what-are-we-signing 
issue anyway; if we can make it do double duty so much the better.

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

That "provided" is actually my biggest reservation with XML.  A plea to 
those discussing the issue: please represent it as simple key/value 
pairs of strings, so there's a direct map between this format and the 
other formats.

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

OK.  This isn't my field of expertise so I'll bow to your better 
judgement.  The only question I'd raise is whether it needs to go into 
this revision of the protocol.  Even though this in fact makes life 
easier for consumer implementors, anything that makes the standard 
longer might put them off.

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

These goals aren't necessarily aligned - agreeing more than one format 
for the consumer to choose between may actually take longer than 
agreeing one format.  On the other hand, it makes a holy war between 
format A and format B impossible.  And as Evan says, for some consumers 
XML will be a completely natural and easy format to parse - in fact, 
this was my original position in my private email to you, in which I 
argued that they'll have to parse XML anyway to retrieve the link tags.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/