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

Meeting record: WSC WG weekly 2007-07-18

From: Thomas Roessler <tlr@w3.org>
Date: Thu, 26 Jul 2007 09:57:27 -0500
To: public-wsc-wg@w3.org
Message-ID: <20070726145727.GN17655@raktajino.does-not-exist.org>

Minutes from last week's meeting were approved:


Thomas Roessler, W3C  <tlr@w3.org>


                     Web Security Context WG Teleconference
                                  18 Jul 2007


   See also: [3]IRC log


          Shawn Duffy, Thomas Roessler, Tyler Close, Jan Vidar Krey, Tim
          Hahn, Stephen Farrell, Hal Lockhart, Audian Paxson, Yngve
          Pettersen, Chuck Wade, Johnathan Nightingale, Luis Barriga, Anil

          Serge Egelman, Rachna Dhamija, Maritza Johnson, Bill Doyle, MEZ




     * [4]Topics
         1. [5]Approve minutes from last meeting
         2. [6]agenda bashing
         3. [7]wsc-usecases progress
         4. [8]rec-track document update
         5. [9]Self Signed Certificates
         6. [10]BrowserLockDown
         7. [11]next meeting
         8. [12]AOB
         9. [13]issue dispositions for the record
     * [14]Summary of Action Items

Approve minutes from last meeting

   <tlr> [15]http://www.w3.org/2007/07/11-wsc-minutes

   <tlr> RESOLUTION: minutes accepted

agenda bashing

   tlr: I have 3 substantive agenda items, any others?
   ... first, review use cases note
   ... also would like an update from sduffy
   ... then self signed certs, then browser lockdown

   <tlr> no changes

wsc-usecases progress

   <tlr> [16]http://www.w3.org/2006/WSC/drafts/wsc-usecases/

   tlr: tyler, can you give us a quick update

   tyler: I think right now, the ball is in my court on a number of things
   ... tlr's note, one or two issues where consensus has been declared,
   but the changes haven't been made
   ... also, some changes tlr suggested in email didn't make it in

   <tlr> process part is ISSUE-73

   tyler: I was hoping to go through threat trees again, but no time

   <tlr> ISSUE-6

   tlr: have you had a look at mobile (issue 6)?
   ... I believe we have 2 proposed additional use cases, and discussion
   seems to have slowed

   tyler: I don't think I've looked at it yet

   <tlr> [17]http://www.w3.org/2006/WSC/Group/track/issues/6

   tyler: are they in the most recent emails, linked from tracker?
   ... I don't see a declaration of consensus

   tlr: we haven't quite declared consensus
   ... I see from the most recent emails that there is one use case, and
   one change to section 10. I'm happy to let this linger, and/or close
   the decision today
   ... any opinions?


   luis: from my side, it looks okay

   tlr: my suggestion to tyler would be to have a look at clearing up
   "prior interaction", extract the use case, extract the changes to
   10.1.1, make the changes, and put it out for reveiw

   tyler: That's possible.

   tlr: by what deadline?

   tyler: you already built in a deadline of next week

   <tlr> ACTION: tyler to extract changes from ISSUE-6, sort out "prior
   interaction" confusion, if any [recorded in

   <trackbot> Created ACTION-269 - Extract changes from ISSUE-6, sort out
   \"prior interaction\" confusion, if any [on Tyler Close - due

   <tlr> ISSUE-38

   <tlr> [20]http://www.w3.org/2006/WSC/Group/track/issues/38


   tlr: this issue has a proposal from Jun 15, no traffic since, I think
   that counts as consensus

   <tlr> RESOLUTION: ISSUE-38 closed; text from Mez to be added to draft

   tlr: given silence on the phone, I'll record it as closed


   tlr: I sent an email with proposed disposition for 11 issues, but
   unfortunately we haven't heard from Bruno or Rob, the originators of
   ... the proposal would be to reassign 78 to rec-track documents, and
   close the others without change, though with extra notes, in some cases
   ... I would like to briefly review a couple
   ... first, 82, shared use, the proposal is to reject this issue since
   we have had ample discussion on "shared systems" already, and closed
   the discussion
   ... next, 88, around information architecture, there hasn't been any
   followup from Bruno as to what that would mean for the group
   ... if anyone can recommend meaningful things around this issue, speak

   tyler: before we leave issue 88, the text description is short, but
   looks similar to language in the note - what's the difference?

   tlr: I understand what the note says about "authoring applications",
   but not what it means to "recommend use of information architecture" in
   any concrete way
   ... issue 94 has at least 4 subpoints...

   <tlr> [23]http://www.w3.org/2006/WSC/Group/track/issues/94

   tlr: first - the portability of settings across platforms and
   technologies - not sure it's in scope


   tlr: of the 4 subpoints, some replicate other issues, and several look
   out of scope
   ... worth noting that mez has added some of this material to the
   future-proofing/PlusOne section of the wiki
   ... if anyone has issues with any of the proposed dispositions, speak
   up now
   ... I propose that we resolve to adopt the recommended dispositions

   <tlr> RESOLVED: issues dispoed as proposed in

   tlr: no objections, resolved

   <tlr> ACTION: thomas to implement issue disposal as described in
   resolution above in minutes [recorded in

   <trackbot> Created ACTION-270 - Implement issue disposal as described
   in resolution above in minutes [on Thomas Roessler - due 2007-07-25].

   tlr: with that, we are down to significantly fewer issues against the

rec-track document update

   <tlr> [27]http://www.w3.org/2006/WSC/drafts/rec/

   <tlr> shawn, please speak up

   sduffy: all the proposals in template format are now in teh document
   ... there are a few that don't quite conform, that have been added
   ... there is one that I wasn't sure what to make of - BMA browser recs
   ... nowhere near template format

   <sduffy> [28]http://www.w3.org/2006/WSC/wiki/BmaBrowserRecommendations

   sduffy: anyone know the state of that

   Chuck: I know what it's about - I think Dan started to incorporate some
   of it with safe browsing mode

   sduffy: Okay, safe browsing has been added

   Chuck: the BMA document precedes the work of this group, and
   anticipates a lot of the issues we are tackling. I don't think it was
   intended as a recommendation, more as a reference document

   sduffy: Okay, I can add that as a reference, but it was in the list of
   recs, so I wasn't sure how to handle it


   sduffy: the ones that still need to be updated are listed in the wiki


   sduffy: the other thing to do is re-arrange the document in accordance
   with Mez' suggestions

   <Zakim> stephenF, you wanted to ask about whether tim H's stuff is in
   that sbm text

   stephenF: the safe browsing mode that Tim H was talking about in dublin
   - did that get rolled in

   <tlr> In the wiki: Browser Lock Down (Added to the Editor's Draft -


   tlr: Tim H's stuff is called Browser Lockdown, and is a separate rec

   stephenF: at some point, someone might say that these things are so
   similar they should be combined

   sduffy: sure, that's possible down the road

   tlr: do we have conformance claims for all the included recommendations
   ... e.g. EV certificates

   sduffy: right, that one is listed as needing update

   tlr: are there others like that?

   sduffy: there are 4 that aren't conforming to the template as a whole,
   but they vary in where they don't adhere to the template

   tlr: my question was, do we have others (except EV) where conformance
   specifically is missing


   tlr: okay, can you prod the authors of the template-breaking ones via

   sduffy: alright. Quick question - we've had a deadline twice already,
   to get updated. If they are not updated by this deadline, do we drop

   tlr: alright, I don't know where RevisitingPastDecisions is lacking, so
   I don't think we should wait too long, but I think it's worth
   discussing where they misconform

   sduffy: alright, I will call that out in the emails

   tlr: and please be clear that if the recommendation is not updated in
   time, they won't be included
   ... we don't have a date for the FPWD

   tyler: are we going to do the usability-specialist markup and review
   before FPWD?

   tlr: I don't know Mez' plan

   tyler: it seems like we should apply our internal expertise before
   soliciting public comment

   tlr: My opinion is that if there is low hanging fruit, I think it
   should be applied, but we don't want to wait for formal high-quality
   ... hard to talk about it with all four usability experts off the call

   tyler: We just risk looking naive, if we don't make meaningful
   reference to the existing usability work in the field

   tlr: As I said, we don't have a solid date for FPWD anyhow, there will
   be more work between now and then
   ... next week is a better week to have this discussion than this week

   <tlr> ACTION: shawn to prod authors of CertErr,
   RecRevisitingPastDecisions, EVCert, Letterhead about template
   conformance; deadline for answers is either this Friday or next meeting
   [recorded in

   <trackbot> Created ACTION-271 - Prod authors of CertErr,
   RecRevisitingPastDecisions, EVCert, Letterhead about template
   conformance; deadline for answers is either this Friday or next meeting
   [on Shawn Duffy - due 2007-07-25].

   tlr: I think that's it for the text of the draft so far - anything

Self Signed Certificates

   stephenF: Let's assume we have consensus around a set of proposals for
   handling TLS certificates in general
   ... after that, the question is what to do differently for self-signed
   ... obviously SS certs come with no guarantees - they are a leap of
   faith - how can that happen without confusing the user, and without
   opening yourself up to attack
   ... if you decide that you want to permit it, how do you mitigate the
   ... it's a hard problem, and we don't want to ignore it

   <johnathjust to get the conversation rolling ... ... one of the obvious
   answers ... ... self-signed certs are dead stop ... ... error page ...
   ... exception: text of the error page could say "if you have good
   reasons, you can do X to override" ... ... then treat cert as otherwise
   valid for that domain ... explicitly extend trust ... ... another way
   of establishing identity ...

   tlr: I put myself on the queue to make an alternative proposal
   ... stephenF mentions the ssh leap of faith
   ... that is, when you have your first interaction with a site, you
   learn the site/key association, but on subsequent visits, if the cert
   changes, noise is made
   ... if the assumption that "in most cases, your first interaction with
   a site is legit" is a valid one, then you're basically safe as long as
   things don't change
   ... and when they do change, you can behave very attack-detected style
   of behaviour

   <stephenF> I like that first-few-as-if-unsecure idea

   tlr: so if there is a downgrade from CA-signed to self-signed, that's
   an error. But if it is the same certificate presented consistently, we
   can start to show trust indicators

   tjh: I wanted to comment on both proposals
   ... I don't like the notion of making the user decide, in either of
   these modes
   ... it would seem to me that SS certs are something we have to handle,
   moreso than just "don't use them"

   <tlr> for the record, the second proposal does not necessarily make the
   user pick

   tjh: maybe just requiring them to retrieve it out of band

   <stephenF> -1 for requiring out-of-band

   tlr: jumping the queue to say that my proposal doesn't require user
   choice up front necessarily

   stephenF: I don't like the idea of requiring an out of band interaction
   ... before you meaningfully improve security, you've already become

   tyler: I also think we need a usable answer, I think they're very

   <tjh> I was thinking more of allowing some "more knowledgeable person"
   to have procured/installed the "right" SS-Certs

   <tjh> and if not there, no-worky.

   tyler: I don't like johnathan's proposal - I have heard the opinion
   expressed that using SSL shouldn't make things worse than HTTP

   <stephenF> +1 for that -1


   tyler: tlr and stephenF both made reference to the ssh model, where you
   only get notified when things change
   ... if you look at the PII editor proposal, there's language around
   determining whether "this is the same site I spoke to last time"
   ... and then the only question is the initial leap of faith
   ... we need extra care there, since secrets are sometimes passed along
   in the first interaction

   <stephenF> leap-of-faith here for SSCs means we also need to consider
   notAfter in the past then and now (just noting that so I don't forget
   so easily:-)

   <tjh> I do like the idea of usage of "is this different than before"
   (history information) in deciding if this is "ok" or not.

   <stephenF> good point to propose "safe" entry points to SSC-secured

   <tlr> -1 to that idea

   tyler: this means we should consider the kind of URL we'd allow for
   leap of faith situations

   <tlr> +1 to "thou shall have entry points"

   tlr: we have 10 minutes left

   stephenF: I think the idea of a safe entry points is a good one

   tlr: I'm heavily against proposing heuristics to gauge "safety" of a
   ... my proposal in that case would be to abstract it a little - "have
   safe entry points" - don't pass secrets when you have reason

   <stephenF> how would I know there's a secret in a URL?

   tyler: when site A is linking to site B, it might expect B to be
   CA-signed. We need the browser to intervene at runtime if it turns out
   that B is less trustworthy
   ... microsoft does that today, with their anti-phishing reporting,
   stripping identifying detail

   Chuck: this issue more than others calls out the fundamental issue with
   how browsers communicate TLS status
   ... I think we have to be fairly crisp about indicating to the user the
   difference between having an encrypted session, and having an
   identified partner
   ... network appliances use self signed certs all the time, and that's
   not going to change, it's important to their operation

   <sduffy> 12 pm meeting... gotta run... I'll prod the authors of the 4
   non-templatified proposals

   Chuck: I know it's hard, but it seems like what's needed is a mechanism
   for pushing certs out to user agents

   <stephenF> trust anchor mgmt anyone?

   <Zakim> stephenF, you wanted to more-or-less agree with tlr on
   leap-of-faith and to ask if its really ok to propose that the browser
   store all certs it sees forever

   tlr: cutting chuck off because stephenF has an answer to the current

   stephenF: trust anchor management is something that the IETF has a BoF
   for next week, which is looking at precisely the topic of delivering
   trust anchors
   ... I do like the idea of a growing trust, where it takes N
   interactions or N days, to establish trust for a SScert
   ... if we go down this route around spotting changing certs, there are
   a lot of details to figure out (e.g. expiry)
   ... that's a fairly complicated bit of context

   Chuck: first of all I do wish I could attend the BoF but it seems

   <yngve> old article: [35]http://my.opera.com/yngve/blog/show.dml/461932

   Chuck: the point I wanted to make was that there have been a variety of
   attempts to help users make/manage trust decisions (e.g. Mac OS

   <stephenF> chuck: if you can arrange someone else from an FI to come to
   the BoF, let me know

   Chuck: the problem is, users don't know how to deal with it, and
   browsers don't communicate it well

   <stephenF> just to note that the assumption here is that we've already
   sorted out the "normal" TLS case

   tlr: I think the IdentitySignal recommendation is a piece of that
   discussions, part might also be about revisiting past decisions

   yngve: this is an area where there are probably no good solutions
   ... what we are probably looking for is the most usable solution. I'm
   not sure I like either of the existing solutions
   ... the problem with keeping the history is that you develop lock in,
   and risk problems during data loss
   ... posted a link to an article of mine in IRC

   <Chuck> Again, in the real world, there are commercial solutions to the
   problem of local history being lost. For example, syncronization
   services can handle this problem, and do for many users

   tlr: are johnathan or stephen interested in taking up this conversation

   stephenF: I'd be happy to work with you on that next week

   <tlr> ACTION: stephen to draft proposal for self-signed certs over beer
   with Thomas [recorded in

   <trackbot> Created ACTION-272 - Draft proposal for self-signed certs
   over beer with Thomas [on Stephen Farrell - due 2007-07-25].

   <Chuck> In my case, my history of trusted certs (and password-web site
   connections) is synchronized across multiple systems, and on a Internet



   tjh: the overview of this recommendation is to allow for the myriad
   config settings to be collected into a set of things that makes sense
   for a given usage case/site list
   ... so if you have a set of sites where javascript would be fine, you
   can turn it on, but off for sites where it might be dangerous
   ... the goal is to greatly reduce the questions asked of the user about
   security settings
   ... instead, collective knowledge of security experts can be used to
   tweak those settings according to browsing mode, which is the only
   thing that is contingent on the user
   ... in cases like corporate-deployed browsers, users shouldn't be
   prompted to change settings, they shouldn't even have the option

   tjh - <reads conformance language from wiki>

   tjh: a colleague of mine remarked that there ought to be a way to
   specify whether or not to start in lockdown mode, and should require
   overt action to break out
   ... seems like this applies to a great many of the use cases
   ... one important limitation is the annoyance that users will
   experience if the configuration is overly restrictive

   <Zakim> stephenF, you wanted to ask if this and sbm should be merged
   (when tim's done with the intro)

   stephenF: I like this idea, and I like SBM, but I think they're really
   the same idea. Should they be merged?

   <Zakim> johnath, you wanted to ask, after tjh's intro, whether this is
   intended to be a voluntary mode or not, particularly for non-corporate
   use cases

   stephenF: it's obviously about setting things like whether to run
   javascript based on the sites being visited

   <tjh> I am open to merging or at least investigating that merge

   <johnath> q to tim (might have talked about this in Dublin) --
   interpretation of discussion was that it would be nice ... ... to
   declaratively say "I want to be safe" ... ... didn't realize it would
   be for instance controlled by admins ... ... or really anything more
   than basically a big button that says "disable dynamic content" ... ...
   rules that are downloaded? ... ... not something built in to the
   browser? .. ... when stephen said these things are the same, took a
   second to realize why ... ... but if framed in terms of corporate
   deployed browser, that does sound a lot like SBM .. .. "here's the
   listof sites, here's what you can / can't do" ... ... "make me safer"
   button is a different story ...

   tjh: I didn't mean to imply a big switch - I use using javascript
   toggle as an example
   ... as for corporate - that too was an example
   ... I tried to bring that out with references to geek squad, or social
   networking groups

   johnath: I am just wondering if this reco involves vanilla out-of-box
   experience, or only with third-party additions

   tjh: I expect that at first it will be purely as an addition, but maybe
   that evolves over the time

   <stephenF> +1 for getting new safe-browsing/lockdown "macros" from
   wherever (with care of course)

   tjh: I expect that users will live in user mode most of the time, and
   only in admin mode when they are ready and willing to make security

   Chuck: the BMA discussions say a fair bit about a need for this
   ... for a website to put some constraints on how a browser will
   interact with it
   ... what is missing is how the website can communicate those
   expectations to the user agent

   <stephenF> just to note that we have the same problem with dkim/ssp and
   there use DNS

   Chuck: right now there's no way for a browser to determine whether a
   given site intends to use javascript

   <Zakim> stephenF, you wanted to ask about level of complexity - is
   #include <tlr-setttings.h> allowed, what about #define foo bar?

   Chuck: I think we should start thinking about practical solutions, even
   if they're imperfect

   stephenF: I assume we are not discussing, though we could, a standard
   way of expressing these settings-bundles

   <tlr> I think that expressing these settings might be a worthwhile
   endeavour, but likely outside of scope here.

   stephenF: I would like to see the settings consider some kind of
   consistency across browser
   ... there are issues of complexity here
   ... which may create problems with composing things, introducing new
   vulnerabilities, etc

   tjh: I haven't gotten as far as figuring out if it's a micro-language,
   or a database, or a .ini file

   tlr: the ability that chuck was hinting at - a way for sites to call
   out the features they want

   johnath: I think WHATWG (?? maybe??) is considering certain limited
   versions of Chuck's idea, like a header tag to request no script
   processing, to prevent XSS

   Chuck: there are quite a few plugins that do things like NoScript, and
   per-site security settings - there's a lot of approaches already
   happening here worth citing

   that sounds like action on Chuck to compile a list :)

   <Zakim> johnath, you wanted to reply to stephen

   <tlr> stephen: Should FPWD have SBM and LockDown separate?

   <johnath> might be useful to get separate comments on them, as they
   might evolve differently ... SBM is whitelist only, to a large extent
   ... ... LockDown sounds richer ... ... separate issues for public
   review, unless everybody insists that they be combined ...

   <Chuck> I agree with Johnath

   <stephenF> counterargument is lockdown seems to include possibility of
   whitelist ... one proposal included in the other ... ... have some text
   that points out the relationship ...

   <johnath> I hear you ... ... broad reading of lockdown could easily
   subsume SBM ...

   tlr: we're out of time - give tjh final word

   <tlr> ... keep them separate, but point out relationship ...

   tjh: definitely want to add the bit about current work, mentioned by
   ... fine by me to leave them separate, but agree that there might be
   language to add

   <Chuck> Re: examples, I'd cite the noscript plugin for Firefox as one
   example, and the OmniWeb browser (Mac only) as an example that allows
   the user to take an extreme degree of fine-grained control over what a
   Web site is allowed to do.

next meeting

   <tlr> next week, 25 July, MEZ to chair


   <tlr> yngve: Yngve @ IETF as well, then vacation & regrets for that

   <stephenF> PHB will probably be in Chicago as well

   <tlr> meeting adjourned

issue dispositions for the record

   <tlr> ISSUE-78 reassigned to rec-track deliverables

   <tlr> ISSUE-79 close without change to Note text

   <tlr> ISSUE-80 close

   <tlr> ISSUE-81 close without change to text

   <tlr> ISSUE-82 reject (and close) since topic was decided

   <tlr> ISSUE-84 close without change

   <tlr> ISSUE-86 close without change

   <tlr> ISSUE-89 close as duplicate of ISSUE-80

   <tlr> ISSUE-93 close without change

   <tlr> ISSUE-94 close; part out-of-scope, part duplicate of ISSUE-87

Summary of Action Items

   [NEW] ACTION: shawn to prod authors of CertErr,
   RecRevisitingPastDecisions, EVCert, Letterhead about template
   conformance; deadline for answers is either this Friday or next meeting
   [recorded in
   [NEW] ACTION: stephen to draft proposal for self-signed certs over beer
   with Thomas [recorded in
   [NEW] ACTION: thomas to implement issue disposal as described in
   resolution above in minutes [recorded in
   [NEW] ACTION: tyler to extract changes from ISSUE-6, sort out "prior
   interaction" confusion, if any [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [42]scribe.perl version 1.128
    ([43]CVS log)
    $Date: 2007/07/26 14:56:13 $


   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0216.html
   3. http://www.w3.org/2007/07/18-wsc-irc
   4. http://www.w3.org/2007/07/18-wsc-minutes.html#agenda
   5. http://www.w3.org/2007/07/18-wsc-minutes.html#item01
   6. http://www.w3.org/2007/07/18-wsc-minutes.html#item02
   7. http://www.w3.org/2007/07/18-wsc-minutes.html#item03
   8. http://www.w3.org/2007/07/18-wsc-minutes.html#item04
   9. http://www.w3.org/2007/07/18-wsc-minutes.html#item05
  10. http://www.w3.org/2007/07/18-wsc-minutes.html#item06
  11. http://www.w3.org/2007/07/18-wsc-minutes.html#item07
  12. http://www.w3.org/2007/07/18-wsc-minutes.html#item08
  13. http://www.w3.org/2007/07/18-wsc-minutes.html#item09
  14. http://www.w3.org/2007/07/18-wsc-minutes.html#ActionSummary
  15. http://www.w3.org/2007/07/11-wsc-minutes
  16. http://www.w3.org/2006/WSC/drafts/wsc-usecases/
  17. http://www.w3.org/2006/WSC/Group/track/issues/6
  18. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0198.html
  19. http://www.w3.org/2007/07/18-wsc-minutes.html#action01
  20. http://www.w3.org/2006/WSC/Group/track/issues/38
  21. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jun/0120.html
  22. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0212.html
  23. http://www.w3.org/2006/WSC/Group/track/issues/94
  24. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0100.html
  25. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0212.html
  26. http://www.w3.org/2007/07/18-wsc-minutes.html#action02
  27. http://www.w3.org/2006/WSC/drafts/rec/
  28. http://www.w3.org/2006/WSC/wiki/BmaBrowserRecommendations
  29. http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals
  30. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jun/0064.html
  31. http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals
  32. http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals
  33. http://www.w3.org/2007/07/18-wsc-minutes.html#action03
  34. http://www.w3.org/2006/WSC/drafts/rec/#piieditor-conformance-association
  35. http://my.opera.com/yngve/blog/show.dml/461932
  36. http://www.w3.org/2007/07/18-wsc-minutes.html#action04
  37. http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/BrowserLockDown
  38. http://www.w3.org/2007/07/18-wsc-minutes.html#action03
  39. http://www.w3.org/2007/07/18-wsc-minutes.html#action04
  40. http://www.w3.org/2007/07/18-wsc-minutes.html#action02
  41. http://www.w3.org/2007/07/18-wsc-minutes.html#action01
  42. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  43. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 26 July 2007 14:57:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:17 UTC