W3C home > Mailing lists > Public > www-tag@w3.org > February 2012

Draft TAG Minutes from 16 Feb.

From: Jonathan A Rees <rees@mumble.net>
Date: Wed, 29 Feb 2012 08:51:47 -0500
Message-ID: <CAGnGFMJiHtJS5jb7mmukEM6i+xxRg7C-6KTUd7jrVeM3cu9qcw@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:45 GMT