- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Sat, 07 Jul 2007 15:44:42 +0100
- To: michael.mccormick@wellsfargo.com
- CC: public-wsc-wg@w3.org
michael.mccormick@wellsfargo.com wrote: > I would be fine with that change. If you wish, go ahead and edit the > CertErr wiki entry with my blessing. Done, S. > -----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 Saturday, 7 July 2007 14:42:53 UTC