On Wed, 2007-18-04 at 21:05 -0500, Mark Wahl wrote:
> Johnny Bufu wrote:
> > The core spec doesn't allow newline characters ("\n") in any openid.*
> > values. Currently, Attribute Exchange doesn't specify a way to encode
> > newlines in attribute values.
> >
> > At a minimum, we could specify a way to escape just the \n character.
> > Other option would be to do something more generic, e.g. URL-encoding
> > the values.
>
> It would be nice if there was a mechanism defined that could
> transfer binary-valued (non-string) attribute values, such as avatar
> 'icon' images, as OpenID AX attribute values. This is currently
> forbidden by section 3 of AX protocol, IIRC. I suggest that if such a
> binary transfer mechanism were defined, then it could be leveraged
> for transferring strings which contain illegal string value characters,
> such as newline.
Base64 encoding is a pretty good candidate for binary data, but you
cannot apply the same encoding to text fields.
Whatever encoding is used for text fields it must be applied every
single time, not only if the string contains illegal characters.
Otherwise there is no way to properly decode the string (how do you know
if you have to decode or not?). Adding an encoding flag for every field
is an overkill IMO.
Applying base64, or similar encoding appropriate for binary data, to
text fields has two drawbacks:
- renders the field unreadable
- increases the size of the field
URL-encoding has the advantage that probably all web frameworks will
have functions to encode and decode this format. The only minor drawback
I can see is the fact that during transport values will end up being
double encoded and this could generate confusion in some instances (like
debugging).
Marius
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
