See also: IRC log
<johnath> looks like progress now
(various musings about success dialogues)
I still am
<stephenF> what's the web conf url?
<johnath> stephenF: http://www.webdialogs.com
<Mez> http://www.w3.org/2008/02/20-wsc-minutes.html
<stephenF> ta
http://www.w3.org/2008/02/20-wsc-minutes.html
mez: well, it seems like we
wanted to publish use cases as a note, as opposed to going to
Last Call
... so do we agree that the resolution was MEANT to be
publication as Note?
... thomas, please manipulate the minutes accordingly
tlr: nods
RESOLUTION: we meant Publish as Note, and approve that
<scribe> ACTION: thomas to work with tyler to get wsc-usecases published as note [recorded in http://www.w3.org/2008/02/27-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-396 - Work with tyler to get wsc-usecases published as note [on Thomas Roessler - due 2008-03-05].
<johnath> Ah, quite so!
mez: no issues there?
yngve: a bit of a complaint about
the web conferencing thing
... they say I don't have the right browser ...
... I'd rather not have to change user agent ...
mez: sorry, it's the only thing I could get hold of on short notice
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0053.html
mez: any issues?
nope
mez: none
<Mez> Logistics for next face-to-face meeting
<Mez> http://lists.w3.org/Archives/Member/member-wsc-wg/2008Feb/0010.html
<Mez> Update on access-control
<Mez> http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0275.html
tlr: before we go to the agenda
bashing, want to beat up Phil
... to get ACTION-387 done ...
<PHB2> what is the web conf code? IO can't find the Mez missive
<maritzaj> 3336389
mez: thomas asked for next f2f
logistics and access-control
... anything else?
... finally the thing that was on the agenda -- "security
confidence estimate"
... next meeting is March 5
tlr: while we're talking "next metings", I think 12 March needs to be cancelled
ian: was?
tlr: 5 March next, then 19 March, cancel 12 March.
<Mez> Logistics for next face-to-face meeting
<Mez> http://lists.w3.org/Archives/Member/member-wsc-wg/2008Feb/0010.html
http://www.w3.org/2006/WSC/Group/logistics-osl.html
http://www.w3.org/2002/09/wbs/39814/wscf2fosl/
yngve: hotels generally full.
Please book early, and avoid surprises.
... you typically can cancel hotel bookings ...
... just to mention an anecdote, even state dept had to
...
... dump diplomats out of town ...
mez: I have an anecdote, too!
yngve: would be good to know if we need to expand the block early
mez: btw, I will need to use an IBM approved hotel
<scribe> ACTION: thomas to add "will use the opera block" to registration form [recorded in http://www.w3.org/2008/02/27-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-397 - Add \"will use the opera block\" to registration form [on Thomas Roessler - due 2008-03-05].
ifette: what's the hotel price?
<serge> it looked like around $140 at the top end
johnath: $140 if you're paid in the wrong dollar
<hal> no info on F2F on http://www.w3.org/2006/WSC/Group/
mez: anything else
tlr: what's your deadline?
yngve: not sure how quickly
... but the sooner the better ...
<scribe> ACTION: thomas to link oslo logistics from WSC/Group [recorded in http://www.w3.org/2008/02/27-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-398 - Link oslo logistics from WSC/Group [on Thomas Roessler - due 2008-03-05].
<johnath> FYI - westhotel.no is just the Oslo Best Western
<Mez> Update on access-control
<Mez> http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0275.html
tlr: Mozilla said they *won't*
ship an implementation that uses ambient auth information
... expect quite a bit of discussion to come up ...
<Mez> 7) Low fi prototyping of security confidence estimate
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#page-score
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0051.html
<Mez> http://lists.w3.org/Archives/Member/member-wsc-wg/2008Feb/0007.html
<Mez> There seemed to be general agreement that we would not go to LC with anything that was not at least lo fi prototyped (unless it was the sort of robustness recommendation where only lack of compliance could be prototyped). Working through the prototyping of SCE in a meeting seemed to be the only possibility for it to make it to LC in June.
mez: I think I was the only one who followed up
<ifette> mez: I cheated and did work
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0051.html
<rachna> At the f2f, Hal mentioned using the Netcraft toolbar as an example
<rachna> http://toolbar.netcraft.com/
hal: what was the question?
rachna: you mentioned that the thing (and the bars that it shows about risk confidence...)
hal: risk rating; red / green /
thermometer
... information from their database ...
... they have records; can tell you how old web site is
...
... country, couple things aroudn ...
mez: nobody seemed fit to turn that into some proposal
<serge> yeah, it's really nice for the user's perspective, because most websites have a small sliver of red
mez: anybody regretting that?
ifette: I don't regret seeing
that proposed ...
... what's the country supposed to tell you ...
... US web site might easily pull in malware from Russia
...
<Mez> there is no plan, other than whatever is in xit that isn't "making it"
ifette: not clear that it's useful information at all ...
hal: thermometer display as an example
<rachna> The problem is that whatever users see frequently becomes a "legitimate" indicator
mez: anybody else want to propose something?
<Mez> ack stephen f
<Zakim> stephenF, you wanted to ask what's the plan for post-June proposals in this space
stephen: wondering if there is or is not a plan that we come back to after June?
mez: stuff that's being left
out
... SCE is one of these things ...
... sense at f2f was that it's not well fleshed out enough to
consider it ...
... people wanted to see *something* ...
... that's what we're looking at ...
rachna: chance for stuff to come back after June?
mez: if we still exist then, why not
serge: regarding the netcraft
toolbar, there's a study known which found this one pretty
useless
... it's in the shared bookmarks ...
... look for "toolbar" ...
<Zakim> ifette, you wanted to discuss mez' proposal
mez: want there to be a conscious decision on SSL state
ifette: rereading MEZ's
proposal
... key point is that (reads e=mail) ...
<tyler> http://www.simson.net/ref/2006/CHI-security-toolbar-final.pdf
tlr: there are some changes in
the pipeline that might affect this ...
... basically, smaller problems ...
mez: mumble
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls
ifette: if somebody decides that
people don't really understand difference between these levels
...
... that should be a good thing ...
... it seems the current idea is a tri-state lock ...
... not sure why that's necessarily better than binary
...
... if implementor wants to give weak same treatment as no tls
...
... not sure why we pick ...
mez: we make that distinction;
there were variants of change of security level ...
... if anything that's explicable only in terms of strong/weak
...
... should make it, then it's possibly important to give
signals ...
<yngve> Opera's multiple level description: http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-all-ev
ifette: thought it wasn't necessarily something that's exposed to user
yngve: just pasted pointer at our
multilevel system
... we don't display a padlock if it's not level 3 ...
... mostly binary now ...
tlr: "weakly TLS" was for cases in which something looks fishy, but has some security properties; idea was "don't tell user about padlock"
hal: if weak tls better than no
tls ...
... by having indicator, encourage web sites to use something
...
... if it's just binary, no visible benefit ...
mez: should i take away that it's 2 state vs 3 state?
ifette: my biggest issue was
binary vs ternary
... if binary, it boils down to lock as implemented in IE / FF
...
mez: my IE doesn't show a negative symbol
ifette: absence of lock as
separate state
... 16x16 block that shows nothing vs 16x16 block that shows
lock ...
mez: I didn't mean it to say it should, but as phrased, it probably does
ifette: if my interpretation was sufficient, I'd be happy
<rachna> I think that we have enough data to know that users don't notice the absence of indicators
ifette: given talk about current best practices, wouldn't be sad if the proposal made it in
mez: anybody seeing something in web conf?
<PHB2> not a sausage
mez: so that would mean we should drop anything that makes tri-state sound attractive
<Mez> remove this http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls
mez: I think it would be removing the second part of the proposal ...
<Mez> remove this
<Mez> The TLS indicator MUST present a state this is only for strongly TLS
<Mez> protected pages. The TLS indicator SHOULD differentiate between a page
<Mez> that is weakly TLS-protected, and one that has no TLS protection at all.
mez: errr, no that's not what I mean
<Mez> Web user agents MUST make information about the [[identity]] of the Web
<Mez> site that a user interacts with and the state of TLS protection available.
<Mez> The [Definition: [[identity signal]] ] and [defn TLS indicator] SHOULD be
<Mez> part of primary user interface during usage modes which entail the
<Mez> presence of signalling to the user beyond only presenting page content.
mez: retain change to 6.1.1 that injects some sort of indicator
<Mez> Otherwise, they MUST at least be available through secondary user
<Mez> interface. Note that there may be usage modes during which this
<Mez> requirement does not apply: For example, a Web browser which is
<Mez> interactively switched into a no-chrome, full-screen presentation mode
<Mez> need not preserve any security indicators in primary user interface.
<Mez> User interactions to access this identity signal or the TLS indicator MUST
<Mez> be consistent across all Web interactions. This includes interactions
<Mez> during which the Web user agent has no trustworthy information about the
<Mez> [[identity]] of the Web site that a user interacts with, and when TLS has
<Mez> not been used to protect those interactions. In the former case, user
<Mez> agents SHOULD indicate that no information is available. In the latter
<Mez> case, they SHOULD indicate the interaction was not TLS protected.
<Mez> User agents with a visual user interface that make the identity signal and
<Mez> TLS indicator available in primary user interface SHOULD do so in a
<Mez> consistent visual position.
<serge> wait, this reads like only EV certs will cause TLS icons to appear?
<serge> it sthat a correct interpretation?
mez: uh, there's something on EV there?
ifette: strongly TLS
protected
... GoDaddy domain validated cert qualifies ...
<serge> yeah, you lose
mez: I only ripped out strong
<serge> well it doesn't matter, because that's not the current text
ifette: what I liked first
sentence that said "there must be state for strongly TLS
protected"
... I think the states should be "strongly TLS protected" vs
"everything else"
serge: the text that you just pasted says that the identity of the site must be known
mez: I haven't changed identity
stuff; changing that is not part of my proposal ..
... I took the current text ...
... and added stuff about TLS indicator ...
... proposal is meant to be adding stuff about TLS indicator
...
serge: going by what you
pasted
... says trustworthy information regarding identity of web site
...
<ifette> My proposed text: The TLS indicator SHOULD have two states. One state SHOULD indicate that the connection is Strongly TLS protected. The other state SHOULD indicate that the connection is not Strongly TLS protected.
<serge> okay, so then what happens to self signed ones?
<serge> the no-TLS indicator?
<serge> that's very confusing
<ifette> serge, probably
<serge> and that would be confusing
<ifette> at least, until it has passed the probation period or whatever
<serge> "uhh, it says HTTPS, but the other indicator says no TLS"
<Mez> Web user agents MUST make information about the state of TLS protection available.
<Mez> The [defn TLS indicator] SHOULD be
<Mez> part of primary user interface during usage modes which entail the
<Mez> presence of signalling to the user beyond only presenting page content.
<Mez> Otherwise, it MUST at least be available through secondary user
<Mez> interface. Note that there may be usage modes during which this
<Mez> requirement does not apply: For example, a Web browser which is
<Mez> interactively switched into a no-chrome, full-screen presentation mode
<Mez> need not preserve any security indicators in primary user interface.
<Mez> User interactions to access the TLS indicator MUST
<Mez> be consistent across all Web interactions.
<Mez> This includes when TLS has
<Mez> not been used to protect those interactions. In this case, web user agents
<Mez> SHOULD indicate the interaction was not TLS protected.
<Mez> User agents with a visual user interface that make the
<Mez> TLS indicator available in primary user interface SHOULD do so in a
<Mez> consistent visual position.
<ifette> +1 to tlr
tlr: I think it should be secure page, strongly tls protected
The TLS indicator SHOULD have two states. One state SHOULD indicate that the web page that the user interacts with currently is a Strongly TLS protected page. The other state SHOULD indicate that the connection is not Strongly TLS protected.
(roughly)
phb: if it's only strong TLS, it's not a TLS indicator
ifette: nobody said ev, we talked about properly configured domain certified
pbaker: this is supplemental to EV indicator?
<ifette> supplimental, i would think
pbaker: is this orthogonal to EV indicator or replacing it?
<ifette> i would not intend this to replace the ev indicator
pbaker: are we *intending* to override EV indicator ...
<ifette> i would think this is a lock refinement
mez: we're talking about TLS / strong TL Sindicator, not Ev
serge: biggest problem is that on
some pages there is going to be https and another indicator
claiming no tLS
... which for the users who bother to notice indicator is going
to be confusing ...
... can't just have two states between not strongly and
strongly protected ...
... there should be at least three states if we differentiate
between different https uri states ...
mez: confusion because of https
url
... which wouldn't be consistently aligned with other
idnicators ...
... is that your argument?
<Zakim> stephenF, you wanted to ask what if both TLS indicator and EV indicator? (if there will be an EV indicator in xit)
serge: it is
<rachna> Serge, I am surprised to hear that you think more states will help maters
<serge> rachna: I don't :)
<rachna> more states = more confusion
stephen: we should decide whether both should be up or one should replace the other
<serge> rachna: I think that'll make this idea less terrible :)
stephen: if there's separate strong TLS and EV, then we should talk about replacing each other
<Zakim> ifette, you wanted to say that https with lock is confusing if the connection is using the null cipher
mez: not sure if anything could cause that problem
<serge> rachna: but at the very least I think that we shouldn't show the absence of the TLS indicator, instead maybe show it with a red circle around it when TLS is missing
ifette: the way I'm reading
proposed text is basically "if there's strongly secure page,
show lock. otherwise, don't"
... serge's point is "https, no lock" means they don't
understand what's going on ...
... point I would like to make is we're nowhere saying that
this is only treatment ...
... all we're saying is "if it's not good, don't show lock"
<PHB2> +1
ifette: all this says is "if not secure page, don't show lock"
<Mez> I had attempted to say that there should be a incdicator whether or not there is tls (strong or otherwise)
ifette: i could see a version of
browsers doing no lock, but having an info bar
... so I don't think the lack of consistency is inherent to
this
FWIW, I don't see anything that's going on in that visual session, either.
<Mez> In this case, web user agents
<Mez> SHOULD indicate the interaction was not TLS protected.
yngve: opera is probably closest
to what Ian was talking about
... currently, not showing padlock ...
... if there's mixed security problem ...
... or OCSP problem ...
... or weak keys involved on encryption ...
... we do show more information in 2ndary chrome ...
... want to do more there than we currently do ...
... think strong TLS indicator should be specified for primary
chrome ...
mez: the primary / secondary stuff was taken from identity signal
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0051.html
(confusion)
<Mez> Web user agents MUST make information about the state of TLS protection available.
<Mez> The [defn TLS indicator] SHOULD be
<Mez> part of primary user interface during usage modes which entail the
<Mez> presence of signalling to the user beyond only presenting page content.
<Mez> Otherwise, it MUST at least be available through secondary user
<Mez> interface. Note that there may be usage modes during which this
<Mez> requirement does not apply: For example, a Web browser which is
<Mez> interactively switched into a no-chrome, full-screen presentation mode
<Mez> need not preserve any security indicators in primary user interface.
<Mez> User interactions to access the TLS indicator MUST
<Mez> be consistent across all Web interactions.
<Mez> This includes when TLS has
<Mez> not been used to protect those interactions. In this case, web user agents
<Mez> SHOULD indicate the interaction was not TLS protected.
<Mez> User agents with a visual user interface that make the
<Mez> TLS indicator available in primary user interface SHOULD do so in a
<Mez> consistent visual position.
<Mez> The TLS indicator SHOULD have two states. One state SHOULD indicate that the connection is Strongly TLS protected. The other state SHOULD indicate that the connection is not Strongly TLS protected.
<Mez> The TLS indicator SHOULD have two states. One state SHOULD indicate that the web page that the user interacts with currently is a Strongly TLS protected page. The other state SHOULD indicate that the connection is not Strongly TLS protected.
<Mez> The TLS indicator MUST present a state this is only for strongly TLS
<Mez> protected pages. The TLS indicator SHOULD differentiate between a page
serge: there are plenty of studies in the shared bookmarks re lock
<Mez> that is weakly TLS-protected, and one that has no TLS protection at all.
serge: that people don't notice
the lcok ...
... I've seen people notice https before noticing lock
...
... still have potential scenario where someone notices https
...
<stephenF> That's all too much text for me to consider in detail now. I'll read xit whenever.
mez: my sense is that everybody is ok with the big paragraph.
<Mez> Web user agents MUST make information about the state of TLS protection available.
<Mez> The [defn TLS indicator] SHOULD be
<Mez> part of primary user interface during usage modes which entail the
<Mez> presence of signalling to the user beyond only presenting page content.
<Mez> Otherwise, it MUST at least be available through secondary user
<Mez> interface. Note that there may be usage modes during which this
mez: so I'm putting it in IRC again ...
<Mez> requirement does not apply: For example, a Web browser which is
<Mez> interactively switched into a no-chrome, full-screen presentation mode
<Mez> need not preserve any security indicators in primary user interface.
<Mez> User interactions to access the TLS indicator MUST
<Mez> be consistent across all Web interactions.
<Mez> This includes when TLS has
<Mez> not been used to protect those interactions. In this case, web user agents
<Mez> SHOULD indicate the interaction was not TLS protected.
<Mez> User agents with a visual user interface that make the
<Mez> TLS indicator available in primary user interface SHOULD do so in a
<Mez> consistent visual position.
<Mez> variant 1) The TLS indicator SHOULD have two states. One state SHOULD indicate that the connection is Strongly TLS protected. The other state SHOULD indicate that the connection is not Strongly TLS protected.
mez: I think we have three proposals on the table here ...
<Mez> variant 2) The TLS indicator SHOULD have two states. One state SHOULD indicate that the web page that the user interacts with currently is a Strongly TLS protected page. The other state SHOULD indicate that the connection is not Strongly TLS protected.
<Mez> variant 3) The TLS indicator MUST present a state this is only for strongly TLS
<Mez> protected pages. The TLS indicator SHOULD differentiate between a page
<Mez> that is weakly TLS-protected, and one that has no TLS protection at all.
<yngve> Yngve's take on what serge was talking about: http://my.opera.com/yngve/blog/show.dml/461932
ifette: don't see Thomas's change in here
mez: 2nd one
ifette: happy if 2nd one is
supposed to cover mixed content considerations
... also, we're not saying there are no other indicators,
right?
phb: to serge, think we need to
first specify that there must be an unambiguous indicator with
correct semantics
... consider triage ...
... later on, go back and propose withdrawing some of the
confusing and conflicting semantics ...
... in particular things like https -- should ask whether
browsers should continue to display https when user hasn't
input it ...
mez: looking forward to concrete proposal on that
phb: premature in round 1 to
propose withdrawing that
... let's first get document out that say "consistent
indicators that give users a fighting chance" ...
<Mez> "give users a fighting chance" - I do like that one
phb: getting rid of clutter should be phase 2 ...
<Zakim> stephenF, you wanted to ask that we don't strawpoll just now, but do it on the list or next week
stephenF: mostly, seems like
things are fairly reasonable, but I'm confused ...
... would hope we can look at text on the mailing list, decide
there, or next week ...
mez: would rather we make decisions at meetings
stephen: multiple paragraphs in editor's draft?
<serge> this is insanity!
<johnath> http://pastebin.mozilla.org/
<johnath> use that!
<johnath> it's what we use
<johnath> :)
stephen: can we have this in the draft?
<johnath> mez ^^
stephen: I don't think it's well-prepared enough ...
<serge> can we move on?
mez: ok, so I'll prepare a place in the wiki
<rachna> I'm off IRC for a few minutes but will be on the phone.
hal: what's variant 1 vs variant 2?
ifette: variant 2 covers mixed content
<serge> so it seems like we're arguing about redefining the TLS icon, when most users don't notice them, and those who do don't currently know what they mean.
hal: want intended difference
ifette: mixed content
<Mez> http://www.w3.org/2006/WSC/wiki/TlsIndicator
hal: does strongly protected TLS include EV?
ifette: EV + proper domain-validated
hal: they don't have to be
augmented assurance?
... is that right?
ifette: yes
yngve: https that user also sees
is good point, but in part can't get away from that
... posted about it in articles ...
<Mez> we're going to the straw poll right after yngve's comments folks
<ifette> http://pastebin.mozilla.org/346814 :-)
hal: don't getting variant
3
... it hasn't have grammar ...
... is this that or what?
http://www.w3.org/2006/WSC/wiki/TlsIndicator
<Zakim> stephenF, you wanted to ask that variant 2 "SHOULD have 2 states" is a bit odd
stephen: If it has 17 states, is it compliant?
tlr: i.e., exactly 2 or at least?
ifette: think exactly
<serge> are we not going to get to Action 389?
<serge> because I need to go soon
stephen: variant 4 -- MUST instead of SHOULD
<ifette> ACTION-389?
<trackbot-ng> ACTION-389 -- Serge Egelman to write up error levels -- due 2008-02-13 -- PENDINGREVIEW
<trackbot-ng> http://www.w3.org/2006/WSC/track/actions/389
stephen: otherwise same as variant 2
<serge> I SHOULD take a shower now, since I MUST go to work today
yngve: what opera has when it comes to EV is no padlock, padlock, padlock on green
<johnath> I think I just fell off the call
ifette: say there MAY be addtl state for AA certs used
<Mez> you can still straw poll
<ifette> The indicator MAY have an additional state to indicate that the connection is protected with an AA certificate.
ifette: happy if that's part of
any of them
... variant 2 ...
<tyler> Since we're adding variants, could we have one for drop this proposal entirely?
mez: presumption is that we have 2, 3, or 4
<ifette> Variant 2 has my vote
<hal> 3
<tyler> none of the above
<anil> I do not see the variants. where are they>?
<jvkrey> http://www.w3.org/2006/WSC/wiki/TlsIndicator
<ifette> http://www.w3.org/2006/WSC/wiki/TlsIndicator
<anil> thank u
<serge> is there a none of the above option?
<jvkrey> 3
<maritzaj> 3
<serge> 3, if these are the only choices
<PHB2> 4
abstain
<PHB2> actually change to 3
<johnath> I'm with serge, I think there's substantial information suggesting that it's near-irrelevant, but 3 among the options
<anil> 2min
<stephenF> i prefer 3 but that preference could change if the definition of strongly-protected changed
<anil> 4
<yngve> 2 but "connection" should be clearer and refer to elements loaded as part of the page
ifette: saw a lot of support for
variant 3
... which basically indicates that lock should be tri-state
...
... strongly TLS protected, weakly, and no TLS ...
... not a usability expert ...
... interested in hearing from Rachna and SErge ...
... heard Rachna say more states mean more confusion ...
... wondering whether the people voting for variant 3 are
saying that there should be indication "weak vs strong",
somewhere ...
... or tri-state ...
yngve: opera had that, moved away from it
hal: how did you determine that it was confusing?
yngve: numbers, etc
<Mez> 2 - ifette
<Mez> 3 - hal, jvkrey, maritzaj, serge, phb2, johnath, stephenf, yngve
<Mez> 4 - anil
<Mez> abstain - tyler, tlr, mez
ifette: 2 also had yngve
<Mez> 2 - ifette, yngve
<Mez> 3 - hal, jvkrey, maritzaj, serge, phb2, johnath, stephenf
<Mez> 4 - anil
<Mez> abstain - tyler, tlr, mez
stephenF: difficulty picking --
all this depends very much on strongly protected
definition
... the result of that could change my vote ...
mez: what we've got now is sth we
can carry forward to june
... that consists of first paragrph and var 3 ...
... with as little inconsistencies and all that as we can get
...
ifette: are we happy carrying var
3 forward?
... this is sth that opera dropped, and ff isn't showing broken
locks ...
... disturbing to me that we are making that suggesting ...
serge: I think we should know what this lookslike
<Zakim> ifette, you wanted to agree with serge, and say that I am really uncomfortable recommending something that all browsers just dropped
ifette: think serge has a good point here
<Zakim> Thomas, you wanted to note that there's "feat;ure at risk"
ifette: don't think this can go into last call ...
<johnath> whoops - phone dropped again
<Zakim> ifette, you wanted to discuss features at risk
tlr: let me observe that there are features at risk which get pruned during candidate rec.
ifette: strongly opposed to
recommending sth that all browsers recently dropped
... think this is a bad move ...
<serge> why?
<serge> we dont' know why they dropped them!
mez: note one browser vendor voted for that variant
<stephenF> did all browsers recently drop tri-state? I didn't hear that, just that opera did and maybe FF3
hal: I think that right now this is the best option; could probably be persuaded otherwise
<serge> best partice is another term for "we have no evidence that this really works"
mez: if there's current practice
that we recognize as good, should put that in the spec
... rest of sce is out of spec for June ...
... nobody proposed any of that ...
... think there's group support and consensus on this ..
ifette: I object, *not* formally, want to go through this on mail
<scribe> ACTION: ifette to try to craft some text that revolves around weak/strong signalling [recorded in http://www.w3.org/2008/02/27-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-399 - Try to craft some text that revolves around weak/strong signalling [on Ian Fette - due 2008-03-05].
Mez: next meeting: march
5th
... attempt to use web conference declared a failure ...
<serge> when are we going to discuss error levels?
<serge> I need to iron out the text
<serge> I don't want it included as written, I know it needs some minor editing
mez: does somebody want it on the agenda
serge: well....
ACTION-399?
<trackbot-ng> ACTION-399 -- Ian Fette to try to craft some text that revolves around weak/strong signalling -- due 2008-03-05 -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/actions/399
tlr: will go through it
adjourned