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

Re: ACTION-240 :TLS errors...

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Sat, 07 Jul 2007 15:44:42 +0100
Message-ID: <468FA6DA.3080808@cs.tcd.ie>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:48 GMT