RE: Notice: hex encoding being changed to lowercase for digest() and hmac() functions

Hi John,

I certainly will update the test case, but I would like to wait until the group reached a decision about if we are going to create a Google Code project for the tests. This will help implementers a lot, when we create the project they don't have to search the e-mail archives anymore why we changed a test, but they can easily track the changes using looking at the commit messages and/or issue tracking system.

Maybe we can make a decision about it on the e-mail list, and then I can create the project this weekend, and do some of the changes we agreed on and propose changes to tests that still need fixing but the WG didn't talked about yet.

Regards,

Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com<mailto:Nick_Van_den_Bleeken@inventivegroup.com>

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of John Boyer
Sent: woensdag 11 maart 2009 21:47
To: public-forms@w3.org
Subject: Notice: hex encoding being changed to lowercase for digest() and hmac() functions


I'd like to minimize the amount of telecon time we have to use on this issue,
so based on the information I have received from various sources (below),
I'll change the XForms 1.1 draft back to lowercase for the hex encoded
results of digest() and hmac().

Nick, can you change the tests to remove the translate() function call, please?

The information has to do with reported implementations:

1) Nick reports that Chiba returns lowercase results

2) Keith Wells reports that the FF plugin returns lowercase results.
He also indicated that a Google search produced hits where
hex encodings of digest values either SHOULD or MUST be
lowercase for compatibility and interoperation with other apps.

3) Next, I asked Merle Sterling about the Ubiquity processor, and he
responded that not only does Ubiquity return the lowercase results,
but that he had  to add the lowercasing code to the FF extension in
order to make it pass the tests.

4) This caused me to realize that anybody who reported a pass
before we changed the test would be already returning lowercase
results, which then covers the EMC processor.

Therefore, we have no implementations that are supporting the
advancement of XForms 1.1 that rely on case insensitivity, and putting
the results to lowercase is an easily implementable programming step.

Best regards,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw



From:

John Boyer/CanWest/IBM@IBMCA

To:

public-forms@w3.org

Date:

03/09/2009 08:34 PM

Subject:

digest() and hmac() function results to lower case


________________________________




Hi all,

Why was it decided that the results of digest() and hmac() would be case-insensitive.
I realize that the algorithms base-64 and hex *could* return upper or lower case letters, but is it really that hard for implementations to push the results to lower case?
It just seems strange to push that translation onto the application author or form author.

It's not a big deal either way, but I'm doing the spec work now, and it just looks so odd to say:

<eg>digest('abc', 'SHA-1', 'hex')</eg>
<p>returns <phrase diff="add">a string that under case-insenstive comparison is equal to </phrase> <code>a9993e364706816aba3e25717850c26c9cd0d89d</code>.</p>

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw


--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--

________________________________
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--