>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 _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
