- From: <michael.mccormick@wellsfargo.com>
- Date: Fri, 6 Jul 2007 15:38:50 -0500
- 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. Stephen.
Received on Friday, 6 July 2007 20:39:13 UTC