Re: encoding newlines in attribute values
On Wed, 2007-18-04 at 23:25 -0700, Douglas Otis wrote: On Apr 18, 2007, at 8:31 PM, Marius Scurtescu wrote: Base64 encoding is a pretty good candidate for binary data, but you cannot apply the same encoding to text fields. RFC4648 URL and Filename safe Base 64 Alphabet might be a good choice. Applying base64, or similar encoding appropriate for binary data, to text fields has two drawbacks: - renders the field unreadable Binary data is often unreadable. True, but text is readable and ideally it should stay like that. - increases the size of the field Base 64 increases the size of the encoded element by about 30%. URL-encoding has the advantage that probably all web frameworks will have functions to encode and decode this format. URL-encoding increases the size of the encoded element by 300%. Only unsafe characters are encoded, not the whole string. Not sure how UTF-8 changes any of this. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: encoding newlines in attribute values
On 18-Apr-07, at 9:47 PM, 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. Every indirect OpenID message would seem to be already url-encoded by the browser, or server as post data .. so \n = %0A (i.e. application/x-www-form-urlencoded mime type) Do we need a pre-url-encode encoding, or can we rely on browsers to do the right thing... I suppose it's helpful to spell it out for non- browser agents that want to pass OpenID messages. If we want to define sending binary data in OpenID messages, maybe we should leverage multipart/form-data. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: encoding newlines in attribute values
On 19-Apr-07, at 7:29 AM, Rowan Kerr wrote: On 18-Apr-07, at 9:47 PM, 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. Every indirect OpenID message would seem to be already url-encoded by the browser, or server as post data .. so \n = %0A (i.e. application/x-www-form-urlencoded mime type) Do we need a pre-url-encode encoding, or can we rely on browsers to do the right thing... I suppose it's helpful to spell it out for non- browser agents that want to pass OpenID messages. I think we do need pre-URL-encoding, mainly because of signatures. In order to calculate the signature the parameters must be put together in a special way and new line characters are not allowed. If we want to define sending binary data in OpenID messages, maybe we should leverage multipart/form-data. Same as above, need to encode for signatures to work. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: encoding newlines in attribute values
On 4/19/07, Marius Scurtescu [EMAIL PROTECTED] wrote: I think we do need pre-URL-encoding, mainly because of signatures. In order to calculate the signature the parameters must be put together in a special way and new line characters are not allowed. Yes. The key-value encoding that's used for POST responses (to associate and check_authentication) is also used in signature generation. This is the source of the restriction on newlines in values, not anything to do with URL encoding. Each attribute already has to define its encoding rules and data-type. The mechanism for encoding a newline can be part of this encoding, if newlines are allowed in the value. Once there is one attribute that has a defined encoding for newline, when new attributes are defined, they can re-use this encoding. Does that sound reasonable? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: encoding newlines in attribute values
On Apr 19, 2007, at 10:46 AM, Josh Hoyt wrote: On 4/19/07, Marius Scurtescu [EMAIL PROTECTED] wrote: I think we do need pre-URL-encoding, mainly because of signatures. In order to calculate the signature the parameters must be put together in a special way and new line characters are not allowed. Yes. The key-value encoding that's used for POST responses (to associate and check_authentication) is also used in signature generation. This is the source of the restriction on newlines in values, not anything to do with URL encoding. Each attribute already has to define its encoding rules and data- type. The mechanism for encoding a newline can be part of this encoding, if newlines are allowed in the value. Once there is one attribute that has a defined encoding for newline, when new attributes are defined, they can re-use this encoding. Does that sound reasonable? That sounds fair, however consistent encoding methods with a standardized syntax should be recommended. Elements like icons, voice, signatures blobs could adopt some type of standardized an overlay template. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
