Field separators, again

[Ken Horn]

Paul Crowley wrote:

> Nathan D. Bowen wrote:
>
>> But instead of colons, why not use = as the separator? Then, as a 
>> bonus, we can describe it in terms of its similarity to "Windows INI 
>> format" or the "Java Properties format".
>
>
> Sounds good to me.  Note that Java is also happy with colons though.
>
+1 on '='  if using text

>>    "dh_public" in place of "dh.gy" (not all Diffie-Hellman 
>> documentation uses the name 'gy')
>
> I'd prefer that the server use a different name than the client for 
> its public part.  Apart from that, I'm agnostic.
>
+1 on something other than dh.gy, more like dh_public, but don't care -- 
server_public?

>>    "digest_type" in place of "auth_type",
>
>
> Definitely not.  What if the next revision uses UMAC?
>
what does auth mean? Authentication? Authorisation? Auth of what/who? To 
whom? I prefer digest, but maybe that's because I don't really know the 
difference between a digest and a MAC. How about "hash_type", cos to me, 
they're all just fancy hash algorithms.

>>    "encryption" in place of "enc" (enc looks like 'encoding' to me),
>>    "encrypted_secret" in place of "enc_secret"
>
>
> Brad explicitly shortened these.
>
+1 on lengthening them, better explicit than implicit as the pytho's 
say. Are we trying to save bytes in urls? thought we had loads of room.

>> If we opt out of the question of which single format to use for 
>> responses, I shudder to think about the question "Why won't you add 
>> my favorite format, too? After all, I see a format-selection step 
>> right there in the protocol..." 
>
>
> I also fear that.  But it will be hard to add formats after the 
> initial revision.  If the consumer can't parse any of the formats in 
> the initial revision, it won't be able to talk to old servers.  If it 
> can, there's no real point in asking for a newer format.  My 
> preference is still for just one format, but Brad has more experience 
> than me here.
>
>> XML data is almost self-documenting. As long as we don't restrict 
>> ourselves to simple name/value pairs, XML gives us the opportunity to 
>> make the response format significantly more declarative and 
>> understandable.
>
>
> Personally, introducing the full complexity of XML gives me The Fear, 
> but I'll leave that to others to debate.

If we are putting content in the requests/responses rather than using 
pure URLs (my preference), then +1 on XML. It doesn't need to be complex 
-- all I ask is that we use a namespace for the elements, and tolerate 
tokens from other namespaces / unexpected elements/attrs (let's avoid 
XSD due to its issues with back/forwards compat). This at least handles 
encodings explicitly (UTF-8 please).