W3C home > Mailing lists > Public > public-wsc-wg@w3.org > July 2007

RE: ACTION-240 :TLS errors...

From: <michael.mccormick@wellsfargo.com>
Date: Fri, 6 Jul 2007 15:38:50 -0500
Message-ID: <8A794A6D6932D146B2949441ECFC9D68040AA129@msgswbmnmsp17.wellsfargo.com>
To: <stephen.farrell@cs.tcd.ie>
Cc: <public-wsc-wg@w3.org>

I would be fine with that change.  If you wish, go ahead and edit the
CertErr wiki entry with my blessing.

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
Sent: Friday, July 06, 2007 7:04 AM
To: McCormick, Mike
Cc: public-wsc-wg@w3.org
Subject: Re: ACTION-240 :TLS errors...

michael.mccormick@wellsfargo.com wrote:
> I think what you're proposing sounds consistent with the 
> recommendations presented in 
> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/CertErr

Generally, yes. Only nit with that that I can see is the phrase:

"Primary UI security context indictors should reflect the error without
displaying details."

That seems to me to encourage developers to include e.g. an error code
in the primary SCI, so I'd rewrite it as:

"Primary UI security context indictors should not reflect the specific
error, but should simply indicate a failure."

My reason for that is that if e.g. someone writes UI code now that knows
about the current TLS error codes, then when a new TLS error code is
added (or some 802.1X error happens, whatever), then they are more
likely to present the user with jargon and/or meaningless bytes. So, IMO
including an error code/number isn't a good idea.

But its a minor nit, compared to pushing the jargon into the 2nd-ary
GUI, which we all seem to be agreeing about.

Received on Friday, 6 July 2007 20:39:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:17 UTC