attribute exchange value encoding

[Drummond Reed]

>Johnny Bufu wrote:
>
>While at IIW, I asked around what people thought about the encoding  
>mechanisms we've added recently, in order to allow for transferring  
>any data types. The consensus was that everyone would prefer  
>something simpler and lighter.
>
>So I've rewritten the encoding section, such that:
>
>- for strings, only the newline (and percent) characters are required  
>to be escaped,
>   (to comply with OpenID's data formats), using percent-encoding;
>
>- base64 must be used for encoding binary data, and defined
>   an additional field for this:
>   	openid.ax.encoding.<alias>=base64
>
>Please review section 3.3 Attribute Values to see if there are any  
>issues.
>
>One remaining question is about the choice of encoding for strings.  
>Percent-encoding (RFC3968) seems the simplest from a spec  
>perspective, however some libraries provide (better) support for the  
>older URL-encoding (RFC1738), which throws '+' characters into the  
>mix. Which do you think would work best for implementers, users, and  
>would cause less interop problems?

Johnny,

FWIW, encoding "+" can be a hassle as it's a legal character in media type
values and is also sometimes used for spaces. I'd vote for pure RFC3986
percent-encoding.

=Drummond