On 27-Apr-07, at 3:46 PM, Johnny Bufu wrote:
The default encoding would then be applied only when a attribute-
specific encoding was not used.
With help from Mark Wahl I've put this into the spec and wrapped up
the remaining issues.
The latest version is in SVN here:
: encoding newlines in attribute values
On 20-Apr-07, at 11:18 AM, Dick Hardt wrote:
To expand on that and include Mark Wahl's proposal about locale
encoding[1] in a standard way for attributes so that the
libraries can
do the right thing 99% of the time.
I would propose that AX data
Hans,
On 30-Apr-07, at 9:22 AM, Granqvist, Hans wrote:
Just so we're all on the same page: Can you post a link
to the referenced proposal?
Mark has announced it here on the list:
http://openid.net/pipermail/specs/2007-April/001630.html
Johnny
Cool, thanks!
-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED]
Sent: Monday, April 30, 2007 9:51 AM
To: Granqvist, Hans
Cc: OpenID specs list
Subject: Re: encoding newlines in attribute values
Hans,
On 30-Apr-07, at 9:22 AM, Granqvist, Hans wrote:
Just so
On 20-Apr-07, at 11:18 AM, Dick Hardt wrote:
To expand on that and include Mark Wahl's proposal about locale
encoding[1] in a standard way for attributes so that the libraries
can do the right thing 99% of the time.
I would propose that AX data have a default encoding that can be
On Apr 19, 2007, at 10:46 AM, Josh Hoyt wrote:
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,
On 20-Apr-07, at 11:05 AM, Douglas Otis wrote:
On Apr 20, 2007, at 10:56 AM, Johnny Bufu wrote:
On Apr 19, 2007, at 10:46 AM, Josh Hoyt wrote:
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
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
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
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
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
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
12 matches
Mail list logo
