- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 13 Aug 2008 17:07:44 +0200
- To: public-wsc-wg@w3.org
Minutes from our meeting on 2008-08-06 were approved and are
available online here:
http://www.w3.org/2008/08/06-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group Teleconference
6 Aug 2008
See also: [2]IRC log
Attendees
Present
Tyler Close, Mez, Thomas Roessler, Ian Fette, Bill Doyle, Phill
Hallam-Baker
Regrets
Johnathan Nightingale, Dan Schutzer, Tim Hahn, Serge Egelman,
Maritza Johnson, Jan Vidar Krey, Yngve Pettersen
Chair
Mez
Scribe
IanFette
Contents
* [3]Topics
1. [4]convene
2. [5]items at risk / how to plan for CR entry
3. [6]Items at Risk
* [7]Summary of Action Items
__________________________________________________________________
<trackbot> Date: 06 August 2008
<tlr> ScribeNick: tlr
convene
mez: hi folks, it's a small call, but still
<Mez> [8]http://www.w3.org/2008/07/16-wsc-minutes.html
RESOLUTION: approved, to be installed in location above
<Mez> [9]http://www.w3.org/2006/WSC/track/actions/open
items at risk / how to plan for CR entry
<scribe> ScribeNick: ifette
Items at Risk
<Mez> [10]http://www.w3.org/2006/WSC/wiki/FeaturesAtRisk for candidate
entry
mez: Here's the table for planed implementation details
<Mez> [11]http://www.w3.org/TR/2008/CR-WCAG20-20080430/
mez: WCAG has an items at risk section, we might have a similar section
... wanted to talk about our options here
<tlr> Scribe: IanFette
mez: look items at risk section
... look at success criteria 1.4.8
... mez reads
... we have basic and advanced conformance levels
... basic is MUST, advanced is MUST + SHOULD
<Mez> [12]http://www.w3.org/TR/wsc-ui/#conformance-levels
mez: for any MUSTs we need at least 2 implementations (period).
tlr: correct
mez: For any SHOULDs
tlr: Question as to whether it makes sense to look at this on a
feature-by-feature basis, or also a performance level basis
... You need to have at least two implementations for each feature.
What we make out of that is up to us
... we have some leeway in how we design things
... what makes sense? Something like "We want to have 2 for each must,
2 for each should, at least 1 that can show basic, at least 1 that
shows advanced"
... that could be one way to go
... dont know if that criteria would succeed
... We already skirt must and should already by having multiple
conformance levels
... so we should follow WCAG's lead
ifette: does advanced have a chance of being implemented?
mez: dunno
... that's the point of items at risk
<tlr> [13]http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
tlr: look at entrance criteria
... should be able to demonstrate two implementations
... if we come out of last call without too much change, can go into
candidate rec, and say "here are the features we might remove"
... present document is clear that the WG must identify in detail what
features are at risk
... how do we demonstrate this in a useful way is the question
mez: somewhere there was "should have 2 interoperable implementations"
tlr: yes
... we have a bunch of must not and should not that are operational
enough
... other point that was interesting is that they were not deeming
implementation by "not exercising" a requirement sufficient
<tlr> ... e.g., logotypes not being implemented
mez: As tlr pointed out, being conformant but not implementing a
feature doesn't count towards 1 of the 2 implementations of the feature
... going in, I would argue philisophically that as a starting place
for each one, we really want two interop. implementations for anything
that is MUST/MUST NOT
... feel same way about SHOULDs
phb: SHOULD NOT might be tricky
... if we have a situation where a certain browser does something, and
we would like it to do things similar to that to make sure that they do
not do something in a particular way, we're unable to talk about that
area at all
<Mez> good point
<Mez> is there a downgrade path?
<Mez> there is no MAY NOT
phb: one of the things we're trying to say is that if you do a feature,
it must not screw the pooch
<Mez> but we did make some MAY negative somewhere I thought
phb: still want to be able to talk about features that people may not
do because if they do them badly, it will cause security issues
tlr: to clarify, we have had at least one case where we say UAs MAY do
something blah blah
... if that is the case the interface MUST be task centric
... by itself it's sane
... however, if nobody implements that MAY
... would assume that we would strike it totally
... tricky
mez: would like to find a concrete example of what phil is referring to
<Mez> [14]http://www.w3.org/2006/WSC/wiki/FeaturesAtRisk
phb: Part of this anticipates things such as mobile web
... only just starting
... some of what we are trying to do is get ahead of the curve
mez: example?
phb: where we talk about flash and pdf and so-on being integrated more
tightly
tlr: where we talk about conformance in the presence of plugins
... thought we solved that one
... dont think that's an example of being ahead of the curve
mez: will play by ear
... MAYs OTOH don't know how we feel about 2 vs 1 implementation
... given that it says all features SHOULD have two, doesn't break down
to must/should/may
... but MAY is our out to say something even w/ no backing
implementation
tlr: do we have any MAYs that come without context of accompanying
MUST/SHOULD
mez: petnames
tlr: petnames themselves have requirements though
tyler: all MAYs
<tlr> [15]http://www.w3.org/TR/wsc-ui/#sec-petnames
tlr: yes, earlier point re: trivial
... would argue that any MAY that comes with a set of criteria like
this
... actually should have some implementation support
mez: 1/2?
tyler: partially done
... will have at least 1
tlr: if conditioned on a MAY, does that relax the criteria for the
MUST/SHOULD?
... do not believe anywhere we say a browser MUST implement TLS
ifette: happy with zero for MAYs, one would be gravy
mez: anything re: accessibility is closer to zero
... audio logotypes etc
<PHB> got to go, traffic accident means I have to pick up kid
tlr: what is at risk is presumably the criteria about rendering of
audio logotypes
phb: writing up in cab forum
tlr: suspect high risk
tyler: with altnames in certificates, firefox provides no apis
... (question to phb)
... follow-up offline
tlr: this is totally optional, implementations may or may not support
this, but if they do support we have comformance language
... similar to petnames
mez: you seem to believe that if there are must or shoulds that you can
get around by not implementing, you would still argument for two
implementations
tlr: yes
... also something around independent implementations
... if you look at "exit criteria" in wcag
<tlr> [16]http://www.w3.org/TR/2008/CR-WCAG20-20080430/#statusnote1
tlr: there are at least for the websites an explicit criteria that the
websites should be distinct and independently developed
... to what extent do we address this
... thing we can defend is two implementations
mez: two different versions of same browser might not be interesting
ifette: firefox + firefox extension does not count as two
implementations of the same feature
tlr: yes, but if we had two separate extensions that exercised a
feature
... that would be different
... two distinct implementations of a feature
... precise meaning in presence of plugins is interesting question
... subtle implications
mez: sounds good
... feeling good about general discussion on this topic
... anything else on this topic?
... SHOULD/MUST/MAY discuss now?
tlr: next step?
mez: next step is to fill out the table
... map out what we need to do to get to CR entry
... for anything where we don't have a statement from two somebodys
... we need to have a heartfelt discussion around that, flag as at risk
... claro?
tyler: who is responsible for writing code? FF, Opera, Tyler with
Petname?
mez: nobody else she knows of
tlr: staikos has wandered off
... could be interesting to ask him for review, if he is interested
mez: paul doing anything?
tlr: ping
NOTE: generalize into we might want to ping some of the less active WG
members
mez: OK, that's it for today
... next time on our favorite show...
... ready to talk about testing, or wait for a while?
tlr: would prefer if that discussion included a few choice people
... rachna, maritza, serge would be good peepz
mez: could we at least talk about the non-usability testing?
tlr: sure
ifette: I may be in beijing next week
mez: adjourned
Summary of Action Items
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [17]scribe.perl version 1.128
([18]CVS log)
$Date: 2008/08/13 15:06:43 $
References
1. http://www.w3.org/
2. http://www.w3.org/2008/08/06-wsc-irc
3. http://www.w3.org/2008/08/06-wsc-minutes.html#agenda
4. http://www.w3.org/2008/08/06-wsc-minutes.html#item01
5. http://www.w3.org/2008/08/06-wsc-minutes.html#item02
6. http://www.w3.org/2008/08/06-wsc-minutes.html#item03
7. http://www.w3.org/2008/08/06-wsc-minutes.html#ActionSummary
8. http://www.w3.org/2008/07/16-wsc-minutes.html
9. http://www.w3.org/2006/WSC/track/actions/open
10. http://www.w3.org/2006/WSC/wiki/FeaturesAtRisk
11. http://www.w3.org/TR/2008/CR-WCAG20-20080430/
12. http://www.w3.org/TR/wsc-ui/#conformance-levels
13. http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
14. http://www.w3.org/2006/WSC/wiki/FeaturesAtRisk
15. http://www.w3.org/TR/wsc-ui/#sec-petnames
16. http://www.w3.org/TR/2008/CR-WCAG20-20080430/#statusnote1
17. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
18. http://dev.w3.org/cvsweb/2002/scribe/
--
Thomas Roessler, W3C <tlr@w3.org>
Received on Wednesday, 13 August 2008 15:08:21 UTC