Josh Hoyt schrieb:
There has been a little discussion in the past about the restriction
on allowed character entity references. I don't think there has been
any about numeric character references, except in lumping them in with
character entity references.
These restrictions live on from
Marius Scurtescu schrieb:
The new attribute values are needed in order to signal an OpenID 2
provider.
Why is this necessary? Is OpenID 2 incompatible? In other words, what
happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x
Provider?
If the OpenID 1.x Provider just ignores
Johnny Bufu schrieb:
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;
This means that '%' characters need to be encoded up to three
Dmitry Shechtman schrieb:
This is definitely an interesting proposal. However, it only attempts to
solve the recycling problem, whereas canonical IDs would solve this and
several more.
I think the best solution would be a Persistent Identifier. If the
OpenID Provider returns a different
Peter Watkins wrote:
7.3.3 in draft 11 says
The openid2.provider and openid2.local_id URLs MUST NOT include entities
other than amp;, lt;, gt;, and quot;. Other characters that would
not be valid in the HTML document or that cannot be represented in the
document's character encoding MUST
Peter Watkins schrieb:
I don't think it's reasonable to expect RP code to be capable of parsing
every possible charset in which an HTML page might be encoded.
I also don't think it's reasonable to specify specific charsets that RPs
should be able to decode and then require OpenID users to
+1 for leaving our XRI and Yadis.
Claus Färber wrote:
Josh Hoyt schrieb:
On 5/17/07, Dmitry Shechtman [EMAIL PROTECTED] wrote:
There has been a simplification suggestion floating around since long ago:
resolve i-names via http[s]://xri.net/.
-1. If XRI is to be included, it should be done
Hi Claus,
On 28-May-07, at 5:55 AM, Claus Färber wrote:
Johnny Bufu schrieb:
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;
This
Johnny Bufu schrieb:
On 28-May-07, at 5:55 AM, Claus Färber wrote:
Johnny Bufu schrieb:
So I've rewritten the encoding section, such that:
This means that '%' characters need to be encoded up to three times:
I'm not sure I follow your reasoning all the way; please see my
comments below and
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
10 matches
Mail list logo
