On 29-May-07, at 2:33 AM, Claus Färber wrote:
Johnny Bufu schrieb:
The attribute metadata can be used to define attribute-specific
encodings, which should deal with issues like this.
Ah, so the _usual_ way is that the metadata (Can this be renamed to
datatype definition? metadata is very
Johnny Bufu schrieb:
I believe the HTTP encoding [1] in the OpenID spec will take care of
this part, i.e. before putting the OpenID + AX message on the wire,
the OpenID layer has to HTTP-encode it.
Maybe Base 64 Encoding with URL and Filename Safe Alphabet (RFC 3548,
section 4) should be
Johnny Bufu schrieb:
The attribute metadata can be used to define attribute-specific
encodings, which should deal with issues like this.
Ah, so the _usual_ way is that the metadata (Can this be renamed to
datatype definition? metadata is very misleading.) defines the
encoding. For binary
I agree with Claus. We may not need a base64 type.
Guoping
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber
Sent: Tuesday, May 29, 2007 3:33 AM
To: specs@openid.net
Subject: Re: attribute exchange value encoding
Johnny Bufu schrieb
Johnny:
I have a couple comments on Section 3.3.2 Default Encoding of a Binary
Value.
First, the character set of standard Base64 encoding is not URL-safe.
Specifically, '+', '/' and '=' need to be URL-encoded. So, we need to
URL-encode the value after base64 encoding.
Secondly, different
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,
On 24-May-07, at 5:15 PM, Johnny Bufu wrote:
Please review section 3.3 Attribute Values to see if there are any
issues.
Of course it helps if there's a link to click on... I missed it in
the previous message:
http://openid.net/svn/filedetails.php?repname=specificationspath=%
