Meeting record: WSC WG weekly 2008-02-13 from Thomas Roessler on 2008-02-27 (public-wsc-wg@w3.org from February 2008)

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 27 Feb 2008 15:17:41 +0100
To: WSC WG <public-wsc-wg@w3.org>
Message-ID: <20080227141741.GA92128@iCoaster.does-not-exist.org>

Minutes from our meeting on 2008-02-13 were approved and are
available online here:

http://www.w3.org/2008/02/13-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
13 Feb 2008

See also: [2]IRC log

Attendees

Present
Tyler Close, Thomas Roessler, Mary Ellen Zurko, Bill Doyle,
Johnathan Nightingale, Yngve Pettersen, Jan Vidar Krey, Hal
Lockhart, Ian Fette, Stephen Farrell, Maritza Johnson, Tim_Hahn

Regrets
DanS, Luis, Bill

Chair
Mary Ellen Zurko

Scribe
Johnathan Nightingale

Contents

* [3]Topics
1. [4]Weekly completed action items
2. [5]Open action items
3. [6]Agenda Bashing
4. [7]Section 7
5. [8]Section 8.1
6. [9]Section 8.2
7. [10]Section 9
8. [11]Section 9.2
9. [12]Section 9.4
10. [13]Section 9.5
11. [14]Section 9.6
* [15]Summary of Action Items
__________________________________________________________________

<trackbot-ng> Date: 13 February 2008

<scribe> ScribeNick: johnath

<tlr_> apologies for minutes lateness re face-to-face

<jvkrey> yeah, me 2

<Mez> [16]http://www.w3.org/2008/01/30-wsc-minutes

Mez: We're going on to approve minutes from last distributed meeting

<Mez> Regret+ Bill E

Mez: previous distributed meeting, january 30th?
... approved

<tlr_> [17]http://www.w3.org/2008/01/30-wsc-minutes.html

Weekly completed action items

Mez: whole bunch from various editors, thank you all

tlr_: have we heard anything from Serge about his actions taken at the
face to face
... I am blocking on some of those
... I take the silence as a no

Mez: anything else on closed action items?

<Mez>
[18]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0009.html

Open action items

<tlr_> ACTION-370?

<trackbot-ng> ACTION-370 -- Bill Doyle to draft language to reference
RFC 3766 or successors in a useful way -- due 2008-03-01 -- OPEN

<trackbot-ng> [19]http://www.w3.org/2006/WSC/track/actions/370

bill-d: question on action-370
... want clarification on what we are trying to nail down, can't really
determine action

Mez: yes, we often lose context over time

<Mez>
[20]http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/att-0011/
wsc20080116.html

Mez: tlr thoughts?

tlr_: loading
... this is the convergence of the "what do we reference for 'strong'
cryptography"
... so the action on Bill was to wrap language around this RFC as being
the reference of choice

bill-d: I looked into that and the rfc named seems to be about VPNs
... I've sent something to the list, if that's the general direction we
want, I can work on the text

<Mez> [21]http://www.w3.org/2006/WSC/track/issues/128

Mez: any other issues on other actions?

Agenda Bashing

Mez: I basically threw in continuations from the face to face

Mez: my memory of sections we didn't discuss are 7, 8.1, 8.2 and I was
fuzzy on 9
... we had strong agreement that we needed a lo-fi prototype of
anything going into last call
... even if we have consensus that it is otherwise ready
... with the exception of robustness recs that would only really have a
"non-compliance" prototype
... I don't think we'll get to sec.9 today, but that's okay because I
think it's critical to have Rachna here for that
... comments, changes?

<Mez> [22]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#ceremonies

Section 7

Mez: I haven't had time to prep, has anyone else on the call
(particularly those who were at F2F) opinions on sections to take to
last call, from this section
... my general intuition is that things in section 7 with affinity to
other sections, anything that relies on the input editor, would be
unprepared for last call

ifette: I still have huge concerns about adoption impact of this text

Mez: I think that would be based on what subset we choose to take to
last call

ifette: Basically, I don't think any text here with "MUST" is ready for
last call

Mez: much of the text was massaged during the f2f

<_tlr> I wonder what the scope of "here" is in ifette's statement

Mez: scrolling down, one thing that catches my eye is "petnames"
... section 7.4
... I see overlap with identity signal there

yngve: question - are you intending to have the entire section in the
requirements document
... the problem with that entire section is that it presumes the safe
form editor, it might stick out like a sore thumb to include it

Mez: I hear you saying that you don't think there's a subset there to
extract
... but I think we still can

<stephenF> +1 to ian/ynvge concerns, but would like to see an edited
verison of this before I decide

tyler: I can take an action to define out petname

<_tlr> johnath: question to tyler is... Plan to define petname so it
can be extract?

<_tlr> tyler: i'll do it independent of the safe form editor

<_tlr> mez: that sounds useful

Mez: the next thing that came to mind was 7.8 and 7.9 as having overlap
with other sections
... so somewhere in robustness, covered the customization aspect
... I feel like the parts of 7.8 that overlap with robustness are
already taken care of

hal: are we using the wrong definition of picture in picture here? I
thoguht it involved chrome being overlaid by web content

tyler: I think it involves content within the browser, chrome within
chrome

Mez: is a contact button an existing thing in some subset of user
agents?

tyler: new concept

Mez: right, I know we had some of that content in a prior discussion,
but now I can't find it

<Mez>
[23]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#change-tls-state

Mez: anyone remember where this "remembering certificates" text was?
... I think we probably can
... I think we probably *can't* integrate 7.9 with that text, though

tyler: In this case, you have an additional piece of information. The
user has already told you that it trusts a particular cert chain

Mez: Right - might even want to consider that issue when extracting out
petname text for your action

<scribe> ACTION: tyler to extract out petnames content, provide
definition independent of section 7 [recorded in
[24]http://www.w3.org/2008/02/13-wsc-minutes.html#action01]

<trackbot-ng> Created ACTION-391 - Extract out petnames content,
provide definition independent of section 7 [on Tyler Close - due
2008-02-20].

Section 8.1

<Mez>
[25]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#techniques-dontm
ix

<Mez> issue-109?

<trackbot-ng> ISSUE-109 -- Should there be recommendations against
favicons? -- OPEN

<trackbot-ng> [26]http://www.w3.org/2006/WSC/track/issues/109

ifette: 8.1.3 the first bullet just seems very strange to me
... agents like Firefox 3 don't even have a lock in the location bar
any more, favicons are very useful to me
... I can't see this MUST NOT, even SHOULD NOT seems strong to me

<stephenF> +1 to comment that this text is liable to be overtaken by
new browser versions

johnath: I thought I proposed alt-text here?

<ifette>
[27]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html

Mez: ah, your text does include a proposal for 8.1.3

bill-d: I don't mind favicons, they just shouldn't be used in secure
chrome

<Mez> > - Web User Agents MAY ignore favorite icon [FAVICON] references

<Mez> > that are part of Web content.

<Mez> > - Web User Agents SHOULD NOT use a 16x16 image in chrome to

<Mez> > indicate security status if doing so would allow the FAVICON to

<Mez> > mimic it.

<Zakim> ifette, you wanted to say that secure chrome in FF2 is not the
same as secure chrome in FF3 and that we dont want to say the location
bar will always be secure chrome

Mez: pasting text in channel for consideration

ifette: My problem with the current wording is that it treats the
location bar as secure chrome, and that's a bad assumption
... I like johnathan's second proposed bullet - don't let the favicon
spoof your security indicator

<stephenF> +1 to jonath's 8.1.3 replacement

Mez: okay, so I think we have a proposal in play, I think that would be
the text to consider for the LC document

tlr: I'll take an action to merge that text

<_tlr> ACTION: thomas to merge
[28]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html
[recorded in
[29]http://www.w3.org/2008/02/13-wsc-minutes.html#action02]

<trackbot-ng> Created ACTION-392 - Merge
[30]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html
[on Thomas Roessler - due 2008-02-20].

Mez: sounds like that is text we can take to last call in June, and our
editors will put that in

Section 8.2

<Mez>
[31]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-trust
edpath

Mez: did we discuss this at the face to face

tlr: I think we discussed this on Feb 5

Mez: where did we get with it?

tlr: it was mentioned

Mez: yes, I added it to the agenda because it was touched but not
resolved

<Mez> Web user agents that proactively present security context
information to the user (or a channel presumed to eventually lead to
the user, such as accessibility aides) MAY accept some presentation
information from the user, and associate that information with parts of
the user interface that are intended or commonly used to communicate
trust information to users.

Mez: I believe the only normative text is what I've pasted
... it's pretty weak

<Mez> In these user agents, the editor bar MUST be displayed using a
theme customized to the user. The user selects this theme at browser
installation time. Changes of this theme MUST involve a user
interaction that is focused on this specific task. The icon for the
Contacts button MUST also be selected by the user at installation time.

Mez: not nearly as strong as the text in 7.8

<stephenF> looks ok to me

Mez: in its current state, I think we can take it to last call
... lobbies for something stronger?
... Alright, we're on track to take that to LC in June

<Mez>
[32]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#authoringAndDepl
oyment

Section 9

Mez: did we do 9.1 in the f2f

<Mez> This specification requires that web pages MUST NOT include trust
indicating images such as padlocks in the web content.

tyler: we did not

<stephenF> what if I sell (physical) padlocks?

<jvkrey> or images of padlocks?

<tlr> [33]http://www.flickr.com/search/?q=padlock&w=all

<tlr> (was the objection at the face-to-face)

yngve: a bit more background text might be a good idea
... with extra text, it could be in LC

Mez: what kind of background text are you talking about?

<_tlr> I think the headline is better than the full text -- it's not
about "use trust indicator like images", but rather about "don't use
them to engineer trust"

<stephenF> +1 to tlr

bill-d: I think of padlocks and favicons - people are going to do
whatever they want with them. If we have an area reserved for secure
chrome, then I don't think we care about restricting content outside of
that

tlr: Having been the one who raised the objection, I think the intent
is a good one - don't use these kinds of images to engineer trust
... "don't use trust indicators in content, don't teach them to look in
content instead of chrome for trust indication"

<stephenF> other than help text on web pages?

<tlr> right

<yngve>
[34]http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/0002.html

<Mez> This specification requires that web pages MUST NOT include trust
indicators from existing user agent chrome in the web content as an
indication of web content trust.

tlr: I think that's what we mean, I think we can get there without
difficulty
... that text looks good, maybe with more background text

Mez: what background text

<Zakim> stephenF, you wanted to ask if that MUST NOT is testable or not

tlr: call out the education implication, explain the consequence

<scribe> ACTION: tlr to draft replacement text for section 9.1 (trust
indicators in content) [recorded in
[35]http://www.w3.org/2008/02/13-wsc-minutes.html#action03]

<trackbot-ng> Created ACTION-393 - Draft replacement text for section
9.1 (trust indicators in content) [on Thomas Roessler - due
2008-02-20].

<Mez> web pages MUST NOT include trust indicators from existing user
agent chrome in the web content as an indication of web content trust.

stephenF: does this rule need to be testable? Is it currently?

<stephenF> audio is bad

<stephenF> +1 to it being testable, but hard here when we're talking
about content

Mez: does anyone think things *shouldn't* be testable

yngve: it may be a question of what testable means

Mez: yes, you're right, but certainly lack of compliance is something a
person can point to
... even if it can't be automated

<stephenF> what if UA picks a new icon that some site was using for N
years before?

<yngve>
[36]http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/att-0002/
unsecure_europcar.PNG

yngve: I linked to a screenshot that I sent to the list a month ago
... this site is an example of what we're trying to prevent

Mez: yes, this is an example of the problem

yngve: they've since changed the site around

bill-d: I have another example

<bill-d> [37]http://www.chase.com/

bill-d: the practice is widespread

<stephenF> and credentials in clear is more easily testable

Mez: okay, I think we've got some examples. This is a challenging
notion to test, no doubt
... it's not clear to me how we'll argue that the rule applies to
particular things

<yngve> [38]http://my.opera.com/yngve/blog/show.dml/281609

<Zakim> johnath, you wanted to ask if Larry is a trust indicator

johnath: Larry is a trust indicator, but so are things like VeriSign
siteseals, or "HackerSafe" certification. Do we intend to ban those? We
should be explicit

yngve: wanted to point out that Larry (passport icon in Firefox 3)
could be a trust indicator
... also some of those badges are hosted on http

Mez: we're not concerned here with whether the site is "actually"
secure, so hosting of the content is beside the point - we are talking
about content co-opting trust indicators

hal: I don't think we have to spend time on direct copying of copyright
content, since that's already against the law

Mez: so far I'm not hearing a request to drop this from last call, just
discussion

ifette: what precisely is the text we're talking about

Mez: there's only one line of normative text there

johnath: isn't thomas rewriting it

<hal> web pages MUST NOT include trust indicators from existing user
agent chrome in the web content as an indication of web content trust.

Mez: no, that's just background

tlr: background and possibly editorial stuff

Mez: sounds like this can go to last call, though I am concerned about
how we'll establish pass/fail here

Section 9.2

An unsecure web page MUST NOT embed a form meant for the user to login.
All login pages MUST be served from secure servers ie. login pages must
be TLS protected. An unsecure page MAY carry a link for the user to
click to be taken to a secure page to enter login information. This
link MUST NOT carry a padlock along with it.

tyler: we did a version of 9.2 at the face to face

<stephenF> did new variation of 9.2 mention javascript?

Section 9.4

Mez: we did the redirect stuff, right?

tyler: we didn't come to a conclusion

<stephenF> ok, I'll ask later

<stephenF> also on this, the 2nd sentence should say user again (to
leave out server-server logins)

<stephenF> fine by me

stephenF: Want to know if the login form being described can include
javascript that logs in

Mez: so back to 9.4, redirects

Web Sites that require their users to be redirected from an unsecure
web page to a secure web page MUST do it as a single step rather than
multi-step (redirect to an unsecure page and then redirect again to a
secure page). This specification recommends that the web page MUST use
direct links to a secure page rather than using redirects.

<Mez> issue-163?

<trackbot-ng> ISSUE-163 -- Make (sure) 9.4 is internally consistent --
OPEN

<trackbot-ng> [39]http://www.w3.org/2006/WSC/track/issues/163

<stephenF> why dislike multiple re-directs?

ifette: I'm a little bit concerned that this might be too strict

<_tlr> the concern is redirect chains from https through http back to
https

<tjh> does this impede something like WS-Federation passive?

<stephenF> that was me I guess

<stephenF> no I'm ok that was before

ifette: I understand that we don't want people bouncing from a to b to
c, but if there are several http redirects on the same site before
landing on https

tyler: I think the concern was that for UIs for EV certs, there is an
implied continuity of secure connection, and that's not the case if
there are http steps

<stephenF> +1 to ian's question, same one I wondered about

ifette: 9.4 to me sounds like it deals with people starting on
something insecure, ending on something secure, and how to handle the
redirects in that process
... I think we agree on the continuity of an already-secure connection

yngve: The concern is heightened attack surface

<stephenF> "attack surface" arugment seems too vague to justify a MUST

yngve: for instance at bank of america when you click a login button

<stephenF> tinyurl

ifette: nothing here is about login buttons, it's just about
redirect-on-load from insecure to secure

stephenF++

ifette: bouncing around in one domain doesn't seem substantially less
safe

yngve: we hardcoded our security indicators to only allow one redirect

<Zakim> johnath, you wanted to surface stephen's point

<Mez> yngve's point seems to be that the redirects make it most
difficult for the browser developer to get the security indicator right

<stephenF> would a MUST rule out OpenID+Yadis? (not sure, probably not
HTTP re-directs)

<Mez> Web Sites that require their users to be redirected from an
unsecure web page to a secure web page SHOULD do it as a single step
rather than multi-step (e.g. redirect to an unsecure page and then
redirect again to a secure page). This specification recommends that
the web page SHOULD use direct links to a secure page rather than using
redirects.

johnath: I think the content authors that declare themselves compliant
are a pretty keen bunch, and would be fine with MUST, but I'm happy to
change to SHOULD if that means we move along - I think the important
point is to provide guidance to those designers that multiple bounces
is a bad practice

<stephenF> if we say "SHOULD" there then it'd be nice to give an
example where its reasonable to not adhere (e.g. tinyurl)

tyler: I think the content authors will look to this spec to clarify
the expectations of browser developers
... so if SHOULD deviates from, say, Opera's expectations, we violate
that assumption

Mez: does anyone object to SHOULD

yngve: I can survive it

Mez: yngve, are you proposing alternate text?

<Zakim> ifette, you wanted to ask yngve a question

Mez: I assume from silence that we'll leave it SHOULD for now

ifette: just to be clear on something yngve said earlier. If I go
http->http->https, I don't get a padlock in opera?

yngve: that's correct

Section 9.5

Mez: we have 12 minutes left

<yngve> Perhaps add "Websites SHOULD consider that some clients may use
stricter determinations of security in non-TLS protected redirects that
terminate at a TLS-protected site

<Mez> Web content SHOULD be designed to enable the a consistent
security user experience across different user agents and devices. Web
site owners SHOULD perform tests of the TLS security and trust features
of their site on various devices.

<Mez> Web site owners operating TLS-protected sites should anticipate
the use of those sites from mobile devices which may have constrained
capabilities e.g. diverging sets of trust anchors or limited
cryptographic mechanisms.

Mez: I don't see any issues against it in the current text
... I'm going to suggest this is LC-ready

<stephenF> 9.5 2nd sentence: is that a new sort of requirement...

<tyler> "the a "

<stephenF> ...asking owner (and not developer) to do stuff?

<stephenF> (but I'm ok with the text)

<_tlr> ACTION: thomas to fix grammar error in 9.5 [recorded in
[40]http://www.w3.org/2008/02/13-wsc-minutes.html#action04]

<trackbot-ng> Created ACTION-394 - Fix grammar error in 9.5 [on Thomas
Roessler - due 2008-02-20].

johnath: this seems like straightforward best practices text to me

tyler: grammar error noted in IRC

yngve: I wrote something recently (to the list?) that might be relevant

Mez: not hearing any objections

Section 9.6

<Mez> Audio logotypes embedded with certificates should be designed to
minimize possible listener confusion and the time that their rendering
takes. Specifically, audio logotypes SHOULD NOT include spoken text.
Audio logotypes MAY include short musical phrases.

<stephenF> seems fine to me

Mez: I feel like the state of the text is pretty good, done in
conjunction with the accessibility group
... going once, going twice

<stephenF> that'd be ok with "SHOULD NOT" since they've a reason to do
it

ifette: if somebody's audio-jingle has their company name it, does that
create a problem?

Mez: for answers on that, we'd have to coordinate with the
accessibility folks

hal: does the spoken text include singing?

Mez: take it to the public email list and we'll get their expertise in

<stephenF> syggest adding: stephenF MUST NOT sing in audio logotypes

tjh: As I read the text, it occurred to me whether we should be
synchronizing visual and audio cues, if both are present

Mez: I think it's worth drafting something, and we probably won't
finish it in the 3 minutes remaining

<scribe> ACTION: tjh to draft elaborated text to section 9.6 re:
synchronization of cues [recorded in
[41]http://www.w3.org/2008/02/13-wsc-minutes.html#action05]

<trackbot-ng> Created ACTION-395 - Draft elaborated text to section 9.6
re: synchronization of cues [on Tim Hahn - due 2008-02-20].

Mez: that's it

Summary of Action Items

[NEW] ACTION: thomas to fix grammar error in 9.5 [recorded in
[42]http://www.w3.org/2008/02/13-wsc-minutes.html#action04]
[NEW] ACTION: thomas to merge
[43]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html
[recorded in
[44]http://www.w3.org/2008/02/13-wsc-minutes.html#action02]
[NEW] ACTION: tjh to draft elaborated text to section 9.6 re:
synchronization of cues [recorded in
[45]http://www.w3.org/2008/02/13-wsc-minutes.html#action05]
[NEW] ACTION: tlr to draft replacement text for section 9.1 (trust
indicators in content) [recorded in
[46]http://www.w3.org/2008/02/13-wsc-minutes.html#action03]
[NEW] ACTION: tyler to extract out petnames content, provide definition
independent of section 7 [recorded in
[47]http://www.w3.org/2008/02/13-wsc-minutes.html#action01]

[End of minutes]
__________________________________________________________________

Minutes formatted by David Booth's [48]scribe.perl version 1.133
([49]CVS log)
$Date: 2008/02/27 14:16:30 $

References

1. http://www.w3.org/
2. http://www.w3.org/2008/02/13-wsc-irc
3. http://www.w3.org/2008/02/13-wsc-minutes.html#agenda
4. http://www.w3.org/2008/02/13-wsc-minutes.html#item01
5. http://www.w3.org/2008/02/13-wsc-minutes.html#item02
6. http://www.w3.org/2008/02/13-wsc-minutes.html#item03
7. http://www.w3.org/2008/02/13-wsc-minutes.html#item04
8. http://www.w3.org/2008/02/13-wsc-minutes.html#item05
9. http://www.w3.org/2008/02/13-wsc-minutes.html#item06
10. http://www.w3.org/2008/02/13-wsc-minutes.html#item07
11. http://www.w3.org/2008/02/13-wsc-minutes.html#item08
12. http://www.w3.org/2008/02/13-wsc-minutes.html#item09
13. http://www.w3.org/2008/02/13-wsc-minutes.html#item10
14. http://www.w3.org/2008/02/13-wsc-minutes.html#item11
15. http://www.w3.org/2008/02/13-wsc-minutes.html#ActionSummary
16. http://www.w3.org/2008/01/30-wsc-minutes
17. http://www.w3.org/2008/01/30-wsc-minutes.html
18. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0009.html
19. http://www.w3.org/2006/WSC/track/actions/370
20. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/att-0011/wsc20080116.html
21. http://www.w3.org/2006/WSC/track/issues/128
22. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#ceremonies
23. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#change-tls-state
24. http://www.w3.org/2008/02/13-wsc-minutes.html#action01
25. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#techniques-dontmix
26. http://www.w3.org/2006/WSC/track/issues/109
27. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html
28. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html
29. http://www.w3.org/2008/02/13-wsc-minutes.html#action02
30. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html
31. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-trustedpath
32. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#authoringAndDeployment
33. http://www.flickr.com/search/?q=padlock&w=all
34. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/0002.html
35. http://www.w3.org/2008/02/13-wsc-minutes.html#action03
36. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/att-0002/unsecure_europcar.PNG
37. http://www.chase.com/
38. http://my.opera.com/yngve/blog/show.dml/281609
39. http://www.w3.org/2006/WSC/track/issues/163
40. http://www.w3.org/2008/02/13-wsc-minutes.html#action04
41. http://www.w3.org/2008/02/13-wsc-minutes.html#action05
42. http://www.w3.org/2008/02/13-wsc-minutes.html#action04
43. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html
44. http://www.w3.org/2008/02/13-wsc-minutes.html#action02
45. http://www.w3.org/2008/02/13-wsc-minutes.html#action05
46. http://www.w3.org/2008/02/13-wsc-minutes.html#action03
47. http://www.w3.org/2008/02/13-wsc-minutes.html#action01
48. http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
49. http://dev.w3.org/cvsweb/2002/scribe/

--
Thomas Roessler, W3C <tlr@w3.org>

Received on Wednesday, 27 February 2008 14:18:35 UTC