If XRIs allow unicode characters and URIs do not, then prefixing <a href="http://xri.net/">http://xri.net/</a> in front of an XRI does <i>not</i> guarantee a proper URI. It merely makes it look like one. But if foreign characters exist in the XRI, they must be properly % encoded for the result to be a proper URI.<br>
<br><div class="gmail_quote">On Thu, Jul 10, 2008 at 11:31 AM, Drummond Reed <<a href="mailto:drummond.reed@cordance.net">drummond.reed@cordance.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Martin's right, Peter -- XRI is one option for Unicode. But you can also use<br>
an internationalized domain name<br>
(<a href="http://en.wikipedia.org/wiki/Internationalized_domain_name" target="_blank">http://en.wikipedia.org/wiki/Internationalized_domain_name</a>) in a regular<br>
URL. It uses Punycode (<a href="http://en.wikipedia.org/wiki/Punycode" target="_blank">http://en.wikipedia.org/wiki/Punycode</a>).<br>
<br>
You can also turn an XRI into an URL by adding an XRI proxy resolver prefix<br>
(such as <a href="http://xri.net/" target="_blank">http://xri.net/</a> -- see my sig below for an example). In that<br>
approach the proxy resolver prefix has nothing to do with the XRI itself, so<br>
there's no need to internationalize the domain name.<br>
<br>
=Drummond<br>
<a href="http://xri.net/=drummond.reed" target="_blank">http://xri.net/=drummond.reed</a><br>
<div class="Ih2E3d"><br>
<br>
> -----Original Message-----<br>
> From: Peter Williams [mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>]<br>
> Sent: Wednesday, July 09, 2008 11:40 PM<br>
> To: Drummond Reed; 'Johnny Bufu'; 'Andrew Arnott'<br>
> Cc: 'OpenID List'<br>
</div><div><div></div><div class="Wj3C7c">> Subject: RE: [OpenID] Canonical OpenID url form<br>
><br>
> So the short form of the story is: use xri for unicode (and then transform<br>
> the xri into an https hxri).<br>
><br>
> Its been a month since I studied xri (and thus have forgotten 80 percent<br>
> of it). I recall there was a syntax to identify the address of the initial<br>
> resolver. Is there a way tha this became the domain name componnt of the<br>
> hxri<br>
><br>
> -----Original Message-----<br>
> From: Drummond Reed <<a href="mailto:drummond.reed@cordance.net">drummond.reed@cordance.net</a>><br>
> Sent: Wednesday, July 09, 2008 11:34 PM<br>
> To: 'Johnny Bufu' <<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a>>; 'Andrew Arnott'<br>
> <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>
> Cc: 'OpenID List' <<a href="mailto:general@openid.net">general@openid.net</a>><br>
> Subject: Re: [OpenID] Canonical OpenID url form<br>
><br>
><br>
> Also for the record, XRIs (which use the IRI character set) have a very<br>
> simple defined transformation into IRIs. Thus when an XRI needs to be sent<br>
> over-the-wire in an HTTP(S) URI, it must first be transformed into an IRI,<br>
> then you follow the IRI spec (RFC 3987) to transform into a URI as Johnny<br>
> describes below. Reverse the process to display back to the user.<br>
><br>
> See<br>
> <a href="http://docs.oasis-open.org/xri/xri-syntax/2.0/specs/cs01/xri-syntax-V2.0-" target="_blank">http://docs.oasis-open.org/xri/xri-syntax/2.0/specs/cs01/xri-syntax-V2.0-</a><br>
> cs.<br>
> html for all the gory details (and they are gory - Unicode is hard).<br>
><br>
> =Drummond<br>
><br>
> > -----Original Message-----<br>
> > From: <a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a> [mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>] On<br>
> > Behalf Of Johnny Bufu<br>
> > Sent: Wednesday, July 09, 2008 10:52 PM<br>
> > To: Andrew Arnott<br>
> > Cc: OpenID List<br>
> > Subject: Re: [OpenID] Canonical OpenID url form<br>
> ><br>
> > For the record, since this continued in an offline thread:<br>
> ><br>
> > The issue is around the User-Supplied Identifiers. OpenID defines them<br>
> > as a type of Identifiers, which in turn defined as HTTP(S) URI or XRIs.<br>
> > HTTP(S) URI do not allow non-ASCII characters.<br>
> ><br>
> > So, out of scope of OpenID, parties accepting IRIs (other than XRIs)<br>
> > should follow the respective authoritative recommendations (i.e.<br>
> > RFC3987) before presenting such strings to the OpenID layer as HTTP<br>
> > URIs, and convert them back to IRI form later on when they need to be<br>
> > displayed back to the users.<br>
> ><br>
> > Johnny<br>
> ><br>
> > On 08/07/08 10:32 PM, Andrew Arnott wrote:<br>
> > > Thanks, Johnny. I've had some conversations with a few other people<br>
> > > who draw the opposite conclusion and believe that the %AB%CD notation<br>
> > > is the canonical form.<br>
> > ><br>
> > > You make a good point about having to unescape the characters from<br>
> > > the URI just above the transport layer, but I believe you're applying<br>
> > > section 4.1 to the URL when it should only be applied to the<br>
> > > key/value pairs. The OpenID ClaimedIdentifier, which by the spec is<br>
> > > the last URL to respond without an HTTP redirect, cannot be in<br>
> > > unicode by the URI specification because unicode characters are not<br>
> > > allowed, whether that is UTF8 or UTF16.<br>
> > ><br>
> > > Name/value pairs passed as part of a querystring may (and as the<br>
> > > section you quote requires) be encoded as UTF-8, but they are<br>
> > > subsequently URI encoded as %AB%CD hex characters (thus doubly<br>
> > > encoded) so they are actually no longer UTF-8 at the transport layer.<br>
> > > Since the OpenID URL, around which all the identity of OpenID is<br>
> > > focused (omiting XRIs which don't suffer from this problem) /is/ at<br>
> > > the transport layer of the way the security requirements force the<br>
> > > claimed identifier to be discovered, is all about the transport<br>
> > > layer, I believe it would be a mistake to add semantics on top of<br>
> > > that and call it canonical.<br>
> > ><br>
> > > What I also realized from some other conversations is that this<br>
> > > doesn't really matter. As long as an OP or RP is consistent within<br>
> > > itself in storing and comparing Claimed Identifiers, whether it<br>
> > > stores and compares %AB%CD or the unicode equivalent character won't<br>
> > > matter to anyone, since on the protocol/wire level it is always<br>
> > > %AB%CD. However, I think unescaping the URL and getting the original<br>
> > > unicode characters back is very useful and should be done for<br>
> > > purposes of displaying to the user.<br>
> > ><br>
> > > I think for the security and guaranteed identity of the protocol,<br>
> > > there is a meaningful side to this though. It has not got to do with<br>
> > > how the claimed identifier is stored, but rather how a unicode<br>
> > > string is escaped for URI transport. A given unicode string may be<br>
> > > represented by more than just one series of bytes. Unicode<br>
> > > characters exist that in UTF-8 or UTF-16 have multiple byte sequences<br>
> > > /for the same character/. Therefore someone who is typing in their<br>
> > > OpenID url to a site using one method during one visit, and then<br>
> > > types it in to the same site using a different method on a subsequent<br>
> > > visit, will only be identified by the RP as the same visitor if<br>
> > > OpenID requires that the RP transforms whatever unicode string is<br>
> > > given by the user to the canonical byte form as defined by the<br>
> > > unicode standard before transit. For example, the letter 'Á' can be<br>
> > > encoded as a single character or using composition by adding an<br>
> > > accent to the A character. Both are legal, but the unicode standard<br>
> > > defines one as canonical (I think). But if a string containing this<br>
> > > character is not canonicalized first, then although the character is<br>
> > > equivalent to the user and to unicode, the encoded %AB%CD string will<br>
> > > be different, resulting in security problems for OpenID because<br>
> > > people could overload a single Identifier just by using different<br>
> > > encodings at an OP, or fail to log into an RP depending on how they<br>
> > > craft their string. By the way, I say 'unicode' in the strict sense,<br>
> > > applying to UTF-8, UTF-16, etc. Unicode is commonly used to refer to<br>
> > > just UTF-16, but this problem applies to all unicode character sizes.<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > So I think OpenID should be more explicit about its unicode support<br>
> > > for Identifiers, including mandating a canonical Unicode form.<br>
> > ><br>
> > > On Tue, Jul 8, 2008 at 9:41 PM, Johnny Bufu <<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a><br>
> > > <mailto:<a href="mailto:johnny.bufu@gmail.com">johnny.bufu@gmail.com</a>>> wrote:<br>
> > ><br>
> > ><br>
> > > On 08/07/08 03:01 PM, Andrew Arnott wrote:<br>
> > ><br>
> > > What is the canonical form of an OpenID URL? One with the %AB%CD hex<br>
> > > encoding for unicode chars in the URL or with the actual unicode<br>
> > > chars? For the purposes of displaying to the user and storing in the<br>
> > > RP's database.<br>
> > ><br>
> > > The spec doesn't seem to have anything to say on this.<br>
> > ><br>
> > ><br>
> > > I believe it does say:<br>
> > ><br>
> > > 4.1. Protocol Messages The OpenID Authentication protocol messages<br>
> > > are mappings of plain-text keys to plain-text values. The keys and<br>
> > > values permit the full Unicode character set (UCS). When the keys and<br>
> > > values need to be converted to/from bytes, they MUST be encoded<br>
> > > using UTF-8 [RFC3629].<br>
> > ><br>
> > > <a href="http://openid.net/specs/openid-authentication-2_0.html#anchor4" target="_blank">http://openid.net/specs/openid-authentication-2_0.html#anchor4</a><br>
> > ><br>
> > ><br>
> > > The reason I think it's not a simple automatic answer is the unicode<br>
> > > chars may be what the user typed in and what exists on the server,<br>
> > > but in transit, these characters are translated to %AB%CD in order to<br>
> > > be validly escaped URI strings.<br>
> > ><br>
> > ><br>
> > > The receiving party must decode them to the original form when they<br>
> > > are extracted from the transport layer.<br>
> > ><br>
> > ><br>
> > > So one could argue that the unicode characters are never part of the<br>
> > > protocol<br>
> > ><br>
> > ><br>
> > > One would then be ignoring the parts of the protocol that do not deal<br>
> > > with the transport layer directly.<br>
> > ><br>
> > ><br>
> > > Johnny<br>
> > ><br>
> > ><br>
> > > !DSPAM:139,48744d86221113907413095!<br>
> > _______________________________________________<br>
> > general mailing list<br>
> > <a href="mailto:general@openid.net">general@openid.net</a><br>
> > <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@openid.net">general@openid.net</a><br>
> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
</div></div></blockquote></div><br>