- From: Jonathan A Rees <rees@mumble.net>
- Date: Wed, 29 Feb 2012 08:51:47 -0500
- To: www-tag@w3.org
Draft minutes from 16 Feb 2012 are here
http://www.w3.org/2001/tag/2012/02/16-minutes.html
and in plain text below.
-Jonathan
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Technical Architecture Group Teleconference
16 Feb 2012
[2]Agenda
[2] http://www.w3.org/2001/tag/2012/02/16-agenda
See also: [3]IRC log
[3] http://www.w3.org/2012/02/16-tagmem-irc
Attendees
Present
Ashok_Malhotra, Jeni_Tennison, Jonathan_Rees, Larry_Masinter,
Noah_Mendelsohn, Yves_Lafon, Robin_Berjon, Henry_S_Thompson,
Peter_Linss
Regrets
Chair
Noah Mendelsohn
Scribe
Jonathan Rees
Contents
* [4]Topics
1. [5]Convene
2. [6]Approve minutes of prior meeting
3. [7]Administrative
4. [8]Note to Jeff Jaffe
5. [9]httpRange-14 call for change proposals
6. [10]Design of APIs for Web Applications
* [11]Summary of Action Items
_________________________________________________________
<trackbot> Date: 16 February 2012
<jar> scribe: Jonathan Rees
<jar> scribenick: jar
Convene
Future regrets as recorded in agenda (none recorded for today)
HT can scribe on the 23rd, until quarter past
Approve minutes of prior meeting
Minutes of the 9th approved by acclaim
<noah> [12]http://www.w3.org/2001/tag/2012/02/09-minutes
[12] http://www.w3.org/2001/tag/2012/02/09-minutes
RESOLUTION: [13]http://www.w3.org/2001/tag/2012/02/09-minutes
accepted as a true record
[13] http://www.w3.org/2001/tag/2012/02/09-minutes
Administrative
Announcement needed for the two notes (HTML/XML and client-side
state) - Yves to do
noah: Actions to close?
Yves: Will check later
(agenda review)
Note to Jeff Jaffe
Going over Jeff's email...
JJ asks, who should be doing what on CA issue?
<masinter> I had an off-list discussion about SSL and privacy which
I can summarize some time, if there's interest, but I won't bring up
the topic unless others want to open it.
<noah> Our note to Jeff:
[14]http://lists.w3.org/Archives/Public/www-tag/2012Feb/0049.html
[14] http://lists.w3.org/Archives/Public/www-tag/2012Feb/0049.html
<noah> Response from Jeff:
[15]http://lists.w3.org/Archives/Public/www-tag/2012Feb/0054.html
[15] http://lists.w3.org/Archives/Public/www-tag/2012Feb/0054.html
<noah> Regarding the Certificate Authority system, Jeff asks:
<noah> "While this is clearly a problem for the Web, it is less
clear to me who the
<noah> TAG thinks should be addressing the topic. If the issues are
SSL security,
<noah> it would presumably be addressed at the IETF. Did the TAG
decompose the
<noah> problem enough to identify who should be doing what?"
<masinter> Short answer to Jeff's question is: no
<masinter> We did not decompose the problem enough to identify who
should be doing what
yves: Followup on www-tag: email from Mike Belshe. Even if we are
decomposing, the main issue is the way centralization of trust in
key mgmt system works, and that goes beyond technical. Huge topic
<masinter> My opinion is that W3C Security activity should engage
with the TAG, IETF security directorate, W3C WebAppSec, and IETF
WebSec groups should engage in this.
<Yves>
[16]http://lists.w3.org/Archives/Public/www-tag/2012Feb/0053.html
[16] http://lists.w3.org/Archives/Public/www-tag/2012Feb/0053.html
lm: [as entered in IRC, see above;] Whether the problem can be
addressed by those groups, I don't think we can analyze, as much as
encourage, and agree to review plans if some arise
<Yves> +1 to Larry
<Ashok> +1
<darobin> +1 too
<noah> Proposed text: The TAG did not "decompose" the question in
the sense you mean. We do agree that most of the technical work will
likely happen outside the TAG and much of it will be outside the
W3C. The TAG, and perhaps those in the Security Activity in W3C,
need to continue to monitor the impact of these threats to the
health of the Web, and to work with IETF and others to ensure that
the solutions are as satisfactory as possible.
noah: Drafting...
<noah> AM: remove first sentence
ashok: remove the first sentence
<masinter> The IETF is pursuing DANE:
[17]https://datatracker.ietf.org/wg/dane/charter/ which might be a
solution
[17] https://datatracker.ietf.org/wg/dane/charter/
yl: mention the security directorates liaison
<masinter> We should ask the liaison group to make sure this topic
is covered
<noah> "We agree that most of the technical work will likely happen
outside the TAG and much of it will be outside the W3C. The TAG, and
perhaps those in the Security Activity in W3C, need to continue to
monitor the impact of these threats to the health of the Web, and to
work with IETF and others to ensure that the solutions are as
satisfactory as possible. We note that there is active liaison
between the security directorate at IETF and the Security Activity
lm: There's an overall liaison between IETF and W3C, maybe a more
specific security one too. Philippe & Thomas?
<noah> "We agree that most of the technical work will likely happen
outside the TAG and much of it will be outside the W3C. The TAG, and
perhaps those in the Security Activity in W3C, need to continue to
monitor the impact of these threats to the health of the Web, and to
work with IETF and others to ensure that the solutions are as
satisfactory as possible. We note that there is active liaison
between the security directorate at IETF and the Security Activity
at
jar: I would remove "most of"
<noah> "We agree that the technical work will likely happen outside
the TAG and much of it will be outside the W3C. The TAG, and perhaps
those in the Security Activity in W3C, need to continue to monitor
the impact of these threats to the health of the Web, and to work
with IETF and others to ensure that the solutions are as
satisfactory as possible. We note that there is active liaison
between the security directorate at IETF and the Security Activity
at W3C, and
<masinter> Last sentence is incomplete
<masinter> "We note that ..."
<noah> "Part one: We agree that the technical work will likely
happen outside the TAG and much of it will be outside the W3C. The
TAG, and perhaps those in the Security Activity in W3C, need to
continue to monitor the impact of these threats to the health of the
Web, and to work with IETF and others to ensure that the solutions
are as satisfactory as possible. "
<noah> part 2: "We note that there is active liaison between the
security directorate at IETF and the Security Activity at W3C, and
of course there is also overall W3C to IETF corrdination, which is
managed on the W3C side by Philippe le Hegaret and Thomas Roessler,
and for IETF by Mark Nottingham."
<masinter> we did hear about DANE but didn't analyze it
<JeniT> +1
<plinss> +1
<masinter> +1
No objection to using Noah's text in response to Jeff. Moving on:
<noah> Jeff further wrote: "Among many other important concerns, the
impact on the W3C specifications
<noah> level needs to be assessed."
(looking at the reasons we care about CA issue, and Jeff's comment)
noah: The WGs should take the lead on reviewing W3C specs.
<noah> OK, Yves +1 is to what JAR just scribed me [Noah] saying
<masinter> is there an interaction with SPDY?
<masinter> i dont' actually know what it means, "impact on W3C
specifications level"
yves: SPDY is orthogonal to CA question.
... doesn't enter in here
<noah> I'm guessing that the word "level" should not be emphasized
in understanding Jeff's question.
<masinter> I don't know what he means
<masinter> I don't think there is any impact on W3C specs,
personally
<JeniT> "We agree that the impact on W3C specifications should be
assessed, and propose that this should be done by the appropriate
WGs"
<masinter> I can't think of any off hand.
<masinter> I don't even know what WGs I would ask
<noah> Proposed response: we agree. We expect that individual
working groups should take the lead in dealing with impact on
particular specifications, and as noted above, the TAG will continue
to play an oversight role, being alert for new issues, or for impact
on specifications that others are missing.
<Yves> it has an impact on trust-related things, like provenance,
but it's up to the group who are designing things based on trust to
assess the impact
<masinter> Or what I would ask them to assess
<masinter> I don't think this affects digital signatures
<masinter> The analysis I got from internal Adobe security
consultants is that this doesn't affect digital signatures
<masinter> I think the previous statement covers this too
noah: Send out a general request - if you think your WG's work is
affected please look into it?
LM: That's not a clear instruction
noah: Consider potential impact...
<masinter> How about "b, and to work with IETF and others to ensure
that the solutions are as satisfactory as possible, and impact on
W3C specs considered."
<noah> Possible note to chairs: "We note there have recently been
compromises to the CA system; there will likely be more. You should
assess whether such compromises will affect the technologies for
which your WGs are responsible."
<masinter> Until there are proposed solutions, there's no benefit to
assessing impact of the problem.
noah: Is it clear that this is mainly an IETF thing, that sec domain
is responsible regarding impact on W3C specs?
<noah> Proposed response: we agree. We expect that individual
working groups should take the lead in dealing with impact on
particular specifications, and as noted above, the TAG will continue
to play an oversight role, being alert for new issues, or for impact
on specifications that others are missing.
lm: That's fine
<JeniT> +1
<plinss> +1
general agreement
<noah> Possible note to chairs: "We note there have recently been
compromises to the CA system; there will likely be more. You should
assess whether such compromises will affect the technologies for
which your WGs are responsible."
<masinter> ask Security activity to sponsor this
plinss: Did that agreement include note to chairs?
<plinss> +1
(scribe: I don't think note to chairs was agreed)
<masinter> i'd rather ask Thomas to alert chairs and manage
responses.
<masinter> just trying not to put the TAG into the loop if it's not
needed
<JeniT> +1 to Larry, think Thomas should be able to frame
appropriate message
<noah> Part 1: We agree that the technical work will happen outside
the TAG and much of it will be outside the W3C. The TAG, and perhaps
those in the Security Activity in W3C, need to continue to monitor
the impact of these threats to the health of the Web, and to work
with IETF and others to ensure that the solutions are as
satisfactory as possible.
<noah> Part 2: We note that there is active liaison between the
security directorate at IETF and the Security Activity at W3C, and
of course there is also overall W3C to IETF corrdination, which is
managed on the W3C side by Philippe le Hegaret and Thomas Roessler,
and for IETF by Mark Nottingham. We suggest that the W3C Security
Activity ensure that other concerned WG's are aware of the problems
with the CA system.
<JeniT> +1
<masinter> +1
agreement
<noah> AGREED WITHOUT OBJECTION
Next item from JJ's email - mobile
<noah> Jeff's comment on mobile Web vs. native mobile:
<noah> "This is a key area of concern. Did the TAG produce a
specific list of
<noah> features that would be appropriate for the Web platform to
help it catch up
<noah> in areas where it is currently behind?"
jenit: There is a list, at a high level, in the note we sent
rb: Not detailed, but it says something. Not sure we can be specific
lm: It's as specific as it should be.
... PhoneGap ?
<masinter> PhoneGap is an example of bridging technology
<noah> Proposed response: Only insofar as we included a high-level
list in our note to you. We believe the Mobile Web Activity is
tracking these things in detail, and they have more domain expertise
than we do. Our goal in this note was to signal that, at a high
level, there is both reason for concern about the likely success of
our overall effort, and reason for optimism that a focused effort
can succeed.
<masinter> [18]http://phonegap.com/
[18] http://phonegap.com/
rb: Do we still have a mobile web activity? Now split over ubiweb
and the other one (webapps)?
<masinter> PhoneGap is open source platform that might mitigate some
of these
noah: There's no list of activities?
<Ashok> I had another thought - Platform apps are typically vetted
by the platform, WebApps are not
lm: This topic came from Robin, yes? But we didn't talk about it
much.
<noah> [19]http://www.w3.org/2007/uwa/Activity.html
[19] http://www.w3.org/2007/uwa/Activity.html
lm: I wonder if PhoneGap fills some of these gaps?
noah: PhoneGap-using apps install like native apps
... Mixed bag, because not linkable
lm: Linkability of native apps is the problem then
noah: Big part of what we mean by "web app".. phonegap is useful but
different
<noah> Mobile Web Initiative Activity
(attempt to untangle w3 activity situation)
<noah> Proposed response: Only insofar as we included a high-level
list in our note to you. We believe the Mobile Web Initiative
Activity is tracking these things in detail, and they have more
domain expertise than we do. Our goal in this note was to signal
that, at a high level, there is both reason for concern about the
likely success of our overall effort, and reason for optimism that a
focused effort can succeed.
rb: Don't specifically mention MWA?
<darobin> replace "Mobile Web Initiative Activity is" with "people
in charge of groups relating to mobile Web applications are"
<masinter> I don't "believe MWI is tracking these things in detail"
since I have no idea what they're doing
<masinter> MWI *should* be tracking these things in detail
<masinter> And if I don't know who the "people in charge .." are,
how can I have a belief about what they're doing?
<Yves> well, it's more the "Ubiquitous Web Applications Activity"
that should be tracking things in details in that area
<Yves> as the topic is really... Web Applications
<noah> Proposed response: Only insofar as we included a high-level
list in our note to you. We believe the people in charge of groups
relating to mobile Web applications should be tracking these things
in detail, and they have more domain expertise than we do. Our goal
in this note was to signal that, at a high level, there is both
reason for concern about the likely success of our overall effort,
and reason for optimism that a focused effort can succeed.
<masinter> they report to Jeff, he can make sure they're doing what
they should be doing
<Ashok> Remove -> and they have more domain expertise than we do
<masinter> +1
<noah> Proposed response: Only insofar as we included a high-level
list in our note to you. We believe the people in charge of groups
relating to mobile Web applications are tracking these things in
detail. Our goal in this note was to signal that, at a high level,
there is both reason for concern about the likely success of our
overall effort, and reason for optimism that a focused effort can
succeed.
<noah> AGREED WITHOUT OBJECTION
<noah> (Moving on) Relating to distributed extensibility and vendor
prefixes, Jeff wrote:
<noah> "Did the TAG discuss solutions? My instincts is that there is
an opportunity to address this by speeding up the pace of
standardization. If everyone is using the same approach - why should
everyone call it "webkit", why can't we just agree?"
<noah> Proposed resolution: In the particalur case cited, which is
CSS, there is very active work in the working group to improve the
situation. The TAG is not discussing more general solutions, and
it's not clear that there is some generic approach that would be
broadly applicable.
<darobin> +1
<masinter> There isn't only webkit, every implementation has its own
selection of features
rb: Most mobile browsers are webkit-based... webkit- prefix is
hurting other browsers who are trying to gain ground
<masinter> This is part of the versioning/distributed extensibility
mess
noah: Jeff is saying, why not just drop the prefix?
<masinter> a vendor prefix is a kind of 'version number'
rb: The prefix thing is rather broken. Would be nice if CSS WG
sorted this out. Not sure we (TAG) need to dive into this
<noah> Proposed resolution: In the particalur case cited, which is
CSS, there is very active work in the working group to improve the
situation. If successful, that effort should settle the question of
when to use -webkit and when not (we note that Webkit engines have
90+% market share on mobile, and that's contributing to the
confusion between vendor-specific and ubiquitous features.)
<noah> [CONTINUED] The TAG is not discussing more general solutions,
and it's not clear that there is some generic approach that would be
broadly applicable.
<masinter>
[20]http://www.w3.org/2001/tag/2011/12/evolution/Identifiers.html
has a section on vendor prefixes
[20] http://www.w3.org/2001/tag/2011/12/evolution/Identifiers.html
lm: Count vendor prefix as part of topic we've been working on (but
not now) - think there might be a general approach, we're just not
working on it now
... Too broad for us to take on right now
<masinter> I'm putting my bets on PhiloWeb at WWW 2012 as a venue
for making progress on the fundamentals.
jt: It would be more accurate to say that the TAG's focus is
currently on other things
<masinter> vendor prefix is not so different from a namespace
<noah> Proposed resolution: In the particular case cited, which is
CSS, there is very active work in the working group to improve the
situation. If successful, that effort should settle the question of
when to use -webkit and when not (we note that Webkit engines have
90+% market share on mobile, and that's contributing to the
confusion between vendor-specific and ubiquitous features.) The TAG
has at times started work in related areas, so far we have not
succeeded [truncated]
yves: media types, HTTP headers... it's not really technical but
social, how to deploy, market share, experimental feature how to
move to standard,... bigger topic than just vendor prefix
lm: How different from an XML namespace?
<masinter> this is related to the issues around "x-" and the
difficulties of putting metadata in names
noah: Details of implementation, environment. Easier to have
redundant properties in CSS, than redundant NSes in XML
rb: You could have it in XML, and it would show the same problems.
Attributes, elements
<noah> Part 1: Proposed resolution: In the particalur case cited,
which is CSS, there is very active work in the working group to
improve the situation. If successful, that effort should settle the
question of when to use -webkit and when not (we note that Webkit
engines have 90+% market share on mobile, and that's contributing to
the confusion between vendor-specific and ubiquitous features.)
<noah> Part 2: The TAG has at times started work in related areas,
so far we have not succeeded in finding a focused conclusion that
would be of value to the community.
rb: If you allow people to add extensions in other namespaces, you
end up with the same mess
<masinter> this is related to
[21]http://www.w3.org/2001/tag/doc/metaDataInURI-31.html use of
metadata in URIs. in this case, the metadata is in the tag that the
vendor prefix is metadata "this is only implemented by this vendor"
[21] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html
noah: Worse with elements because in CSS you can specify both, but 3
elements remain different
<masinter> this is a 'version number for forking'
noah: Workarounds maybe, but not same as CSS. E.g. XSL rules
<masinter> because the backward compatibility requirements only work
for a single "fork"
<JeniT> "The TAG has at times started work in related areas, but our
current focus is not on this work."
jar [in IRC]: "The TAG has at times started work in the general area
of extensibility, but we are not currently pursuing this."
<JeniT> +1
<noah> +1
<Ashok> +1
lm: not focusing (instead of pursuing)
<masinter> "we are not currently focusing on this"
lm: so we are pursuing, just not in foreground
<noah> "The TAG has at times started work in the general area of
extensibility, but versioning and extensibility is a known hard
problem in computer science, and right now we are not focusing on
it."
ashok:
<noah> Part 1: In the particular case cited, which is CSS, there is
very active work in the working group to improve the situation. If
successful, that effort should settle the question of when to use
-webkit and when not (we note that Webkit engines have 90+% market
share on mobile, and that's contributing to the confusion between
vendor-specific and ubiquitous features.)
<noah> Part 2: The TAG has at times started work in the general area
of extensibility, but we are not currently focusing on this."
lm: not currently a priority item.
... ok
no objection
<noah> AGREED WITHOUT OBJECTION Part 1 and (the last) PART 2
noah: I will send a response
<JeniT> +1
<masinter> +1
<masinter> I think this dicussion was useful
<noah> ACTION: Noah to respond to Jeff Jaffe, on the public list,
using the text agreed on the telcon of 16 Feb 2012 [recorded in
[22]http://www.w3.org/2012/02/16-tagmem-irc]
[22] http://www.w3.org/2012/02/16-tagmem-irc
<trackbot> Created ACTION-671 - Respond to Jeff Jaffe, on the public
list, using the text agreed on the telcon of 16 Feb 2012 [on Noah
Mendelsohn - due 2012-02-23].
<noah> ACTION-563?
<trackbot> ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG
key issues reports to Jeff per June 2011 F2F Due 2011-10-15 -- due
2012-01-31 -- PENDINGREVIEW
<trackbot> [23]http://www.w3.org/2001/tag/group/track/actions/563
[23] http://www.w3.org/2001/tag/group/track/actions/563
ht: June is too soon for next one
<noah> ACTION-563?
<trackbot> ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG
key issues reports to Jeff per June 2011 F2F Due 2011-10-15 -- due
2012-09-25 -- OPEN
<trackbot> [24]http://www.w3.org/2001/tag/group/track/actions/563
[24] http://www.w3.org/2001/tag/group/track/actions/563
httpRange-14 call for change proposals
<noah> Can we get links to pertinent documents for the minutes?
<noah> HT: I've given you feedback on the UDDP(?) document. Mostly
you can respond later, but there was one typo you need to address
before publishing
<JeniT>
[25]http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html
[25] http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html
<ht> [26]http://www.w3.org/2001/tag/doc/uddp/
[26] http://www.w3.org/2001/tag/doc/uddp/
<noah> scribenick: noah
<jar> JAR will read HT's email on the subject
HT: I think this is the right next step in a judiciously planned
process of trying to wind up in a better place than last time, i.e.
to have more buy in.
<jar> ht: This is the next step in a judiciously planned process to
try to end up better off than we were last time
<scribe> scribenick: jar
ht: [afterwards maybe it would be] time to move into a community
process, I think that's appropriate
... If it doesn't work, we have a basis for creating a new effort,
community group maybe
<noah> I heard Henry say that the time to move to a community
process is >after< feedback is received from Jonathan's call
jar: yes
<ht> Noah is correct
<ht> Step 1: Call for change proposals
<ht> Step 2: Use the result as the basis for moving to some form of
community process, exact form TBD, emphasis on getting broad
consensus
<ht> That's just my memory of what JAR already proposed
noah: Any objections to proceeding as planned? ... Seems not.
<ht> IOW, I'm happy for JAR to go ahead and Call for Proposals
noah: JAR, go ahead and publish the call.
(discussion of agenda)
Design of APIs for Web Applications
Discussion started 2nd Feb (see agenda)
<noah> Discussion on 2 February:
[27]http://www.w3.org/2001/tag/2012/02/02-minutes#item08
[27] http://www.w3.org/2001/tag/2012/02/02-minutes#item08
<noah> Proposal from Robin to expand the scope:
[28]http://www.w3.org/2001/tag/2012/02/02-minutes#item08
[28] http://www.w3.org/2001/tag/2012/02/02-minutes#item08
rb: Audience. People *currently* writing specs?
<noah> Proposal from Robin to expand the scope:
[29]http://lists.w3.org/Archives/Public/www-tag/2012Feb/0021.html
[29] http://lists.w3.org/Archives/Public/www-tag/2012Feb/0021.html
<noah> Draft product page from robin:
[30]http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.h
tml
[30] http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
<noah> From the draft product page:
<noah> "This covers multiple related approaches to preserving users'
privacy:
<noah> * User-mediated enumeration.
<noah> * Device-triggered access.
<noah> * API minimisation
rb: The initial product page was focused on minimization. I
broadened it slightly, not to boil ocean, but just to include
fingerprinting. The two are hard to separate
... Minimization only looks at information you give away when
returning from a method call, as opposed to info you give away right
at the start
<masinter> remember GeoLocation vs. GeoPriv controversy over API
design that wasn't minimimization
rb: There are 4 WGs looking at fingerprinting. I don't think it's a
huge broadening, just more coherent, and more relevant
<Zakim> ht, you wanted to agree that it's time to move from
bilateral discussion to something which gets the parties to engage
on pain of being vulnerable to a "you had your chance"
<Zakim> JeniT, you wanted to encourage the TAG to let Robin work on
this
<masinter> one of the questions about SPDY and privacy was whether
use of SSL improved ability to fingerprinting
jt: I wanted to say that this sounded useful, we can get somewhere
when someone is enthusiastic on topics, so Robin needs to be
encouraged
<Zakim> masinter, you wanted to remind about GeoLocation vs. GeoPriv
lm: There was a controversy between geolocation and geopriv. Policy
re private data APIs saying duration and rights should always be
included. Please add as a use case.
<masinter> it's an API design issue
<masinter> i'm not asking you to look at the issue all over again,
but rather consider the use case where additional policy information
in the API might be useful
rb: I want to steer clear of that, it's bait for flame throwing.
Most of the proponents of geopriv have moved on to other solutions.
CDT
lm: I didn't want to revisit, just to look at increasing API design
is a precedent on API design advice (?)... don't revisit, just use
as use case
noah: Sounds like people are supportive of Robin's plan. Can we look
at product page?
<masinter> topics and products should be defined by their center
rather than their boundaries
[31]http://www.w3.org/2001/tag/products/apiminimization.html
[31] http://www.w3.org/2001/tag/products/apiminimization.html
<masinter> Note that the success criteria don't explicitly require
'minimization' in the solution space
<darobin> [32]http://www.w3.org/2001/tag/doc/APIMinimization.html
[32] http://www.w3.org/2001/tag/doc/APIMinimization.html
[33]http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.h
tml
[33] http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
noah: We could treat this as a new document with new schedule
rb: Lots of good stuff in what Dan did.
noah: You're proposing a draft for the April F2F.
<masinter> i'm willing to do early review of other people's
documents
noah: Propose to adopt RB's draft
<noah> . PROPOSED RESOLUTION: The TAG agrees to work on a "product"
on Privacy by Design as described in
[34]http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.h
tml
[34] http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
<noah> RESOLUTION: The TAG agrees to work on a "product" on Privacy
by Design as described in
[35]http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.h
tml
[35] http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
<noah> Agreed without dissent
<noah> [36]http://www.w3.org/2001/tag/products/
[36] http://www.w3.org/2001/tag/products/
noah: Increase priority after seeing next draft?
(maybe)
<noah> NM: We will keep this as "Other Active Project" for this
round, hope to move it up.
ADJOURNED
Summary of Action Items
[NEW] ACTION: Noah to respond to Jeff Jaffe, on the public list,
using the text agreed on the telcon of 16 Feb 2012 [recorded in
[37]http://www.w3.org/2012/02/16-tagmem-irc]
[37] http://www.w3.org/2012/02/16-tagmem-irc
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [38]scribe.perl version 1.135
([39]CVS log)
$Date: 2012/02/29 13:48:39 $
[38] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[39] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 29 February 2012 13:52:16 UTC