Subject: [dix] character encoding in draft-merrells-dix-00.txt

From: robert yates <[email-masked]>
Date: Sat, 25 Feb 2006 13:05:00 -0500

Am no expert on character encodings, but are there a few issues with the 
current draft and character encoding?  Namely,

1) The fields dix:/message-type, dix:/membersite-url, dix:/signature and 
possibly others require Latin characters in their contents.  However 
isn't a browser free to post the form with a character encoding that 
does not permit these characters?
2) The Canonicalization Algorithm relies on the browser posting the form 
in the same character encoding used by the server to generate it.  With 
the current draft this can this be guaranteed?

This article 
http://www-306.ibm.com/software/globalization/misc/code_considerations/index.jsp 
provides for a good overview of the problem, although may be a bit out 
of date. Having read this what do folks think of the following proposal 
to address the above issues.

The dix spec ensures that information is always exchanged (via the 
browser) encoded as UTF8.  It does this by stating that the character 
encoding of the forms pages must be UTF8 and also mandates the following 
rules for the html forms used for the data transportation.
1. The HTML head section of the form MUST contain <META 
http-equiv="Content-Type" content="text/html; charset=utf-8">. There 
needs to be a corresponding statement for XHTML.
2. The FORM element MUST contain the Accept-Charset attribute and it 
MUST be set to 'utf-8'i.e. <FORM Accept-Charset="utf-8" Type= ...>

The Canonicalization Algorithm can also now probably be simplified a bit 
by stating that the sort is a byte sort of the utf8 representation. 
Also, does it not make sense to have the verify step be a REST style xml 
web service vs. this current form POST.  XML seems much better suited to 
these character encoding issues than 
"application/x-www-form-urlencoded".  Who knows whether the libraries 
for Ruby, Python, Java et al will be consistent with how they perform 
their character encoding.

**Rob

p.s.  also in the spirit of internationalization I notice references to 
first and last name properties in the specification.  Have you 
investigated the possibility of using vCards xml namespace " 
http://www.w3.org/2001/vcard-rdf/3.0#" for identifying user properties?

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Dick Hardt <[email-masked]>
Date: Sat, 25 Feb 2006 10:41:31 -0800

On 25-Feb-06, at 10:05 AM, robert yates wrote:

> Am no expert on character encodings, but are there a few issues  
> with the current draft and character encoding?  Namely,
>
> 1) The fields dix:/message-type, dix:/membersite-url, dix:/ 
> signature and possibly others require Latin characters in their  
> contents.  However isn't a browser free to post the form with a  
> character encoding that does not permit these characters?
> 2) The Canonicalization Algorithm relies on the browser posting the  
> form in the same character encoding used by the server to generate  
> it.  With the current draft this can this be guaranteed?
>
> This article http://www-306.ibm.com/software/globalization/misc/ 
> code_considerations/index.jsp provides for a good overview of the  
> problem, although may be a bit out of date. Having read this what  
> do folks think of the following proposal to address the above issues.
>
> browser) encoded as UTF8.  It does this by stating that the  
> character encoding of the forms pages must be UTF8 and also  
> mandates the following rules for the html forms used for the data  
> transportation.
> 1. The HTML head section of the form MUST contain <META http- 
> equiv="Content-Type" content="text/html; charset=utf-8">. There  
> 2. The FORM element MUST contain the Accept-Charset attribute and  
> it MUST be set to 'utf-8'i.e. <FORM Accept-Charset="utf-8" Type= ...>

Great suggestion!

---

From: Dick Hardt <[email-masked]>
Date: Sat, 25 Feb 2006 10:55:42 -0800

On 25-Feb-06, at 10:05 AM, robert yates wrote:
>
>  Also, does it not make sense to have the verify step be a REST  
> style xml web service vs. this current form POST.  XML seems much  
> better suited to these character encoding issues than "application/ 
> x-www-form-urlencoded".

We had a fair amount of discussion on this. We chose POST although it  
is less elegant then a REST style call because we did not see any  
functional advantage, and for the following implementation advantages;

1) Currently, the HS is not having to parse any HTML or XML, and the  
MS is only generating pretty standard HTML. A little more complexity  
in adding XML to the base.

2) The HS is already getting POSTs on the Homesite-URL for the other  
messages. By having the verify message be another POST in the same  
format, it was thought it would be easier  to implement a HS. The  
unique ID for the HS is the Homesite-URL, as it is in the Persona  
document and is where the MS sends all requests, either directly or  
indirectly.

> Who knows whether the libraries for Ruby, Python, Java et al will  
> be consistent with how they perform their character encoding.

I am pretty sure they are consistent.