IRC log of tagmem on 2012-02-16

Timestamps are in UTC.

18:03:13 [RRSAgent]
RRSAgent has joined #tagmem
18:03:13 [RRSAgent]
logging to http://www.w3.org/2012/02/16-tagmem-irc
18:03:15 [trackbot]
RRSAgent, make logs public
18:03:17 [trackbot]
Zakim, this will be TAG
18:03:17 [Zakim]
ok, trackbot, I see TAG_Weekly()1:00PM already started
18:03:18 [trackbot]
Meeting: Technical Architecture Group Teleconference
18:03:18 [trackbot]
Date: 16 February 2012
18:03:31 [Zakim]
+Jonathan_Rees
18:03:48 [jar]
scribe: Jonathan Rees
18:03:51 [jar]
scribenick: jar
18:04:05 [jar]
chair: Noah Mendelsohn
18:04:19 [jar]
topic: Convene
18:04:34 [Zakim]
+Yves
18:05:04 [Zakim]
+??P12
18:05:14 [jar]
regrest recorded in agenda
18:05:53 [Zakim]
+darobin
18:06:16 [jar]
HT can scribe on the 23rd, until quarter past
18:06:27 [jar]
topic: Approve minutes of prior meeting
18:06:46 [jar]
acclaim
18:06:48 [noah]
http://www.w3.org/2001/tag/2012/02/09-minutes
18:07:02 [jar]
RESOLVED: http://www.w3.org/2001/tag/2012/02/09-minutes accepted as a true record
18:07:10 [JeniT]
JeniT has joined #tagmem
18:07:30 [jar]
topic: Administrative
18:07:49 [Zakim]
+??P17
18:08:30 [jar]
Announcement needed for the two notes (HTML/XML and client-side state) - Yves to do
18:08:57 [jar]
noah: Actions to close?
18:09:04 [jar]
Yves: Will check later
18:09:21 [jar]
topic: Note to Jeff Jaffe
18:10:26 [jar]
(agenda review)
18:10:36 [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.
18:12:01 [noah]
Our note to Jeff: http://lists.w3.org/Archives/Public/www-tag/2012Feb/0049.html
18:12:20 [noah]
Response from Jeff: http://lists.w3.org/Archives/Public/www-tag/2012Feb/0054.html
18:13:00 [noah]
Regarding the Certificate Authority system, Jeff asks:
18:13:08 [noah]
"While this is clearly a problem for the Web, it is less clear to me who the
18:13:08 [noah]
TAG thinks should be addressing the topic. If the issues are SSL security,
18:13:08 [noah]
it would presumably be addressed at the IETF. Did the TAG decompose the
18:13:08 [noah]
problem enough to identify who should be doing what?"
18:13:35 [masinter]
Short answer to Jeff's question is: no
18:14:00 [masinter]
We did not decompose the problem enough to identify who should be doing what
18:14:03 [jar]
Going over Jeff's email...
18:14:24 [jar]
JJ asks, who should be doing what on CA issue?
18:15:13 [jar]
yves: Followup on www-tag Mike Belshi. Even if we are decomposing, the main issue is the way centralization of trust in key mgmt syste, works, and that goes beyond technical. Huge topic
18:15:20 [masinter]
My opinion is that W3C Security activity should engage with the TAG, IETF security directory, W3C WebAppSec, and IETF WebSec groups should engage in this.
18:15:25 [Yves]
s/Belshi/Belshe/
18:15:35 [Yves]
http://lists.w3.org/Archives/Public/www-tag/2012Feb/0053.html
18:16:08 [jar]
lm: (as entered in IRC) Whether the problem can be addressed by those group, I don't think we can analyze, as much as encourage, and agree to review plans if some arise
18:16:14 [Yves]
+1 to Larry
18:16:20 [Ashok]
+1
18:16:23 [masinter]
s/directory/directorate/
18:16:24 [darobin]
+1 too
18:16:37 [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.
18:16:40 [jar]
noah: Drafting...
18:17:31 [noah]
AM: remove first sentence
18:17:34 [jar]
ashok: remove the first sentence
18:17:41 [masinter]
The IETF is pursuing DANE: https://datatracker.ietf.org/wg/dane/charter/ which might be a solution
18:17:58 [jar]
yl: mention the security directorates liaison
18:17:59 [masinter]
We should ask the liaison group to make sure this topic is covered
18:18:11 [noah]
"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. We note that there is active liaison between the security directorate at IETF and the Security Activity
18:18:20 [noah]
s/do agree/agree/
18:18:54 [jar]
lm: There's an overall liaison between IETF and W3C, maybe a more specific security one too. Philippe & Thomas?
18:19:30 [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
18:19:51 [jar]
I would remove "most of"
18:20:10 [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
18:20:11 [masinter]
Last sentence is incomplete
18:20:23 [masinter]
"We note that ..."
18:20:50 [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. "
18:21:00 [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."
18:21:15 [jar]
"likely" ...
18:21:54 [jar]
forget my "" then
18:22:02 [masinter]
we did hear about DANE but didn't analyze it
18:22:10 [JeniT]
+1
18:22:17 [plinss]
+1
18:22:21 [masinter]
+1
18:22:31 [jar]
No objection to using Noah's text in response to Jeff.
18:22:55 [noah]
Jeff further wrote: "Among many other important concerns, the impact on the W3C specifications
18:22:55 [noah]
level needs to be assessed."
18:23:33 [jar]
(looking at the reasons we care about CA issue, and Jeff's comment)
18:23:50 [jar]
noah: The WGs should tak the lead on reviewing Yves specs.
18:23:55 [jar]
s/Yves/W3C/
18:24:07 [noah]
OK, Yves +1 is to what JAR just scribed me saying
18:24:28 [masinter]
is there an interaction with SPDY?
18:24:58 [masinter]
i dont' actually know what it means, "impact on W3C specifications level"
18:25:04 [jar]
yves: SPDY is orthogonal to CA question.
18:25:31 [jar]
… doesn't enter in here
18:25:32 [noah]
I'm guessing that the word "level" should not be emphasized in understanding Jeff's quesiton.
18:25:39 [noah]
s/quesiton/question/
18:26:02 [masinter]
I don't know what he means
18:26:12 [masinter]
I don't think there is any impact on W3C specs, personally
18:26:21 [JeniT]
"We agree that the impact on W3C specifications should be assessed, and propose that this should be done by the appropriate WGs"
18:26:24 [masinter]
I can't think of any off hand.
18:26:34 [masinter]
I don't even know what WGs I would ask
18:26:54 [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.
18:26:54 [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
18:26:56 [masinter]
Or what I would ask them to assess
18:27:06 [masinter]
I don't think this affects digital signatures
18:27:27 [masinter]
The analysis I got from internal Adobe security consultants is that this doesn't affect digital signatures
18:28:12 [masinter]
I think the previous statement covers this too
18:28:15 [jar]
noah: Send out a general request - if you think your WG's work is affected please look into it?
18:28:47 [jar]
LM: That's not a clear instruction
18:29:23 [jar]
noah: Consider potential impact...
18:29:49 [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."
18:30:11 [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."
18:30:45 [masinter]
Until there are proposed solutions, there's no benefit to assessing impact of the problem.
18:30:59 [jar]
noah: Is it clear that this is mainly an IETF thing, that sec domain is responsible regarding impact on W3C specs?
18:32:13 [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.
18:32:21 [jar]
lm: That's fine
18:32:25 [JeniT]
+1
18:32:33 [plinss]
+1
18:32:38 [jar]
general agreement
18:32:50 [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."
18:33:04 [masinter]
ask Security activity to sponsor this
18:33:06 [jar]
plinss: Did that agreement include note to chairs?
18:33:10 [plinss]
+1
18:33:22 [jar]
(don't think this was agreed)
18:33:25 [masinter]
i'd rather ask Thomas to alert chairs and manage responses.
18:33:44 [masinter]
just trying not to put the TAG into the loop if it's not needed
18:33:44 [JeniT]
+1 to Larry, think Thomas should be able to frame appropriate message
18:34:03 [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.
18:34:08 [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.
18:34:15 [JeniT]
+1
18:34:18 [masinter]
+1
18:34:25 [jar]
agreement
18:34:29 [noah]
AGREED WITHOUT OBJECTION
18:34:56 [jar]
Next: mobile
18:35:08 [noah]
Jeff's comment on mobile Web vs. native mobile:
18:35:10 [noah]
"This is a key area of concern. Did the TAG produce a specific list of
18:35:10 [noah]
features that would be appropriate for the Web platform to help it catch up
18:35:10 [noah]
in areas where it is currently behind?"
18:35:54 [jar]
jenit: There is a list, at a high level, in the note we sent
18:36:33 [jar]
rb: Not detailed, but it says something. Not sure we can be specific
18:36:39 [jar]
lm: It's as specific as it should be.
18:37:09 [jar]
lm: PhoneGap ?
18:37:10 [masinter]
PhoneGap is an example of bridging technology
18:37:11 [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.
18:37:34 [masinter]
http://phonegap.com/
18:38:00 [jar]
rb: Do we still have a mobile web activity? Now split over ubiweb and the other one (webapps)?
18:38:19 [masinter]
PhoneGap is open source platform that might mitigate some of these
18:39:06 [jar]
noah: There's no list of activities?
18:39:28 [Ashok]
I had another thought - Platform apps are typically vetted by the platform, WebApps are not
18:39:40 [jar]
lm: This topic came from Robin, yes? But we didn't talk about it much.
18:39:48 [noah]
http://www.w3.org/2007/uwa/Activity.html
18:39:58 [jar]
… I wonder if PhoneGap [missed]?
18:40:38 [jar]
noah: PhoneGap-using apps install like native apps
18:40:51 [jar]
… Mixed bag, because not linkable
18:40:59 [jar]
lm: Linkability of native apps is the problem then
18:41:14 [jar]
noah: Big part of what we mean by "web app".. phonegap useful but different
18:42:10 [masinter]
s/[missed]/fills some of these gaps/
18:42:16 [noah]
Mobile Web Initiative Activity
18:42:24 [jar]
(attempt to untangle w3 activity situation)
18:42:37 [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.
18:43:02 [jar]
rb: Don't sepcifically mention MWA?
18:43:07 [jar]
s/sep/spe/
18:43:28 [darobin]
replace "Mobile Web Initiative Activity is" with "people in charge of groups relating to mobile Web applications are"
18:43:38 [masinter]
I don't "believe MWI is tracking these things in detail" since I have no idea what they're doing
18:43:49 [masinter]
MWI *should* be tracking these things in detail
18:44:23 [masinter]
And if I don't know who the "people in charge .." are, how can I have a belief about what they're doing?
18:44:24 [Yves]
well, it's more the "Ubiquitous Web Applications Activity" that should be tracking things in details in that area
18:44:39 [Yves]
as the topic is really... Web Applications
18:45:16 [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, 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.
18:45:39 [masinter]
s/are tracking/should be tracking/
18:45:51 [masinter]
they report to Jeff, he can make sure they're doing what they should be doing
18:46:16 [Ashok]
Remove -> and they have more domain expertise than we do
18:46:16 [masinter]
+1
18:46:41 [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.
18:47:17 [noah]
AGREED WITHOUT OBJECTION
18:47:41 [noah]
Relating to distributed extensibility and vendor prefixes, Jeff wrote:
18:47:46 [noah]
"Did the TAG discuss solutions? My instincts is that there is an
18:47:46 [noah]
opportunity to address this by speeding up the pace of standardization. If
18:47:46 [noah]
everyone is using the same approach - why should everyone call it "webkit",
18:47:46 [noah]
why can't we just agree?"
18:47:57 [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.
18:48:05 [darobin]
+1
18:49:12 [masinter]
There isn't only webkit, every implementation has its own selection of features
18:49:23 [jar]
rb: Most mobile browsers are webkit-based… webkit- prefix is hurting other browsers who are trying to gain ground
18:49:44 [masinter]
This is part of the versioning/distributed extensibility mess
18:49:58 [jar]
noah: Jeff is saying, why not just drop the prefix?
18:50:24 [masinter]
a vendor prefix is a kind of 'version number'
18:50:36 [jar]
rb: The prefix thing is rather borken. Would be nice if CSS WG sorted this out. Not sure we (TAG) need to dive into this
18:50:41 [jar]
s/bork/brok/
18:50:55 [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.) The TAG is not discussing more general solutions, and it's not clear that there
18:51:00 [masinter]
http://www.w3.org/2001/tag/2011/12/evolution/Identifiers.html has a section on vendor prefixes
18:51:14 [noah]
The TAG is not discussing more general solutions, and it's not clear that there is some generic approach that would be broadly applicable.
18:52:17 [jar]
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
18:52:44 [jar]
lm: Too broad for us to take on right now
18:53:02 [masinter]
I'm putting my bets on PhiloWeb at WWW 2012 as a venue for making progress on the fundamentals.
18:53:06 [jar]
jt: It would be more accurate to [missed]
18:53:22 [JeniT]
s/[missed]/say that the TAG's focus is currently on other things/
18:53:36 [masinter]
vendor prefix is not so different from a namespace
18:53:38 [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.) The TAG has at times started work in related areas, so far we have not succeede
18:53:57 [jar]
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
18:54:15 [jar]
lm: How different from an XML namespace?
18:54:32 [masinter]
this is related to the issues around "x-" and the difficulties of putting metadata in names
18:54:37 [jar]
noah: Details of implementation, environment. Easier to have redundant properties in CSS, than redundant NSes in XML
18:54:56 [jar]
rb: You could have it in XML, and it would show the same problems. Attributes, elements
18:55:07 [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.)
18:55:14 [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.
18:55:26 [jar]
rb: If you allow people to add extensions in other namespaces, you end up with the same mess
18:55:40 [masinter]
this is related to 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"
18:56:01 [jar]
noah: Worse eith elements because in CSS you can specify both, but 3 elements remain different
18:56:09 [masinter]
this is a 'version number for forking'
18:56:20 [jar]
noah: WOrkarounds maybe, but not same as CSS. E.g. XSL rules
18:56:25 [masinter]
because the backward compatibility requirements only work for a single "fork"
18:57:18 [JeniT]
"The TAG has at times started work in related areas, but our current focus is not on this work."
18:58:09 [jar]
"The TAG has at times started work in the general area of extensibility, but we are not currently pursuing this."
18:58:15 [JeniT]
+1
18:58:18 [noah]
+1
18:58:24 [Ashok]
+1
18:58:41 [jar]
lm: not focusing (instead of pursuing)
18:59:04 [masinter]
"we are not currently focusing on this"
18:59:06 [jar]
… so we are pursuing, just not in foreground
18:59:34 [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 this."
18:59:44 [noah]
s/this/it/
19:00:13 [jar]
ashok:
19:00:29 [noah]
Part 1: 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.)
19:00:37 [noah]
Part 2: The TAG has at times started work in the general area of extensibility, but we are not currently pursuing this."
19:00:50 [noah]
s/particalur/particular/
19:01:27 [noah]
Part 2: The TAG has at times started work in the general area of extensibility, but we are not currently focusing on this."
19:01:42 [jar]
lm: not currently a priority item.
19:01:46 [jar]
lm: ok
19:02:12 [jar]
no objection
19:02:17 [noah]
AGREED WITHOUT OBJECTION Part 1 and (the second) PART 2
19:02:49 [jar]
noah: I will send a response
19:02:50 [JeniT]
+1
19:02:52 [masinter]
+1
19:03:03 [masinter]
I think this dicussion was useful
19:03:23 [noah]
ACTION: Noah to respond to Jeff Jaffe, on the public list, using the text agreed on the telcon of 16 Feb 2012
19:03:24 [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].
19:03:53 [noah]
ACTION-563?
19:03:53 [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
19:03:53 [trackbot]
http://www.w3.org/2001/tag/group/track/actions/563
19:04:55 [jar]
ht: June is too soon for next one
19:05:14 [noah]
ACTION-563?
19:05:14 [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
19:05:14 [trackbot]
http://www.w3.org/2001/tag/group/track/actions/563
19:05:38 [noah]
topic: httpRange-14
19:05:45 [Ashok]
q+
19:05:47 [noah]
Can we get links to pertinent documents for the minutes?
19:06:24 [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
19:06:43 [jar]
topic: httpRange-14 call for change proposal
19:06:46 [JeniT]
http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html
19:07:03 [jar]
q?
19:07:03 [ht]
http://www.w3.org/2001/tag/doc/uddp/
19:07:10 [noah]
scribenick: noah
19:07:14 [jar]
ack next
19:07:30 [jar]
JAR will read HT's email on the subject
19:10:19 [ht]
q+ 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" critique
19:11:11 [jar]
q?
19:12:06 [noah]
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.
19:12:09 [jar]
ht: This is the next step in aj udiciously planned process to try to end up better off than we were last time
19:12:17 [noah]
scribenick: jar
19:12:41 [jar]
ht: time to move into a community process, I think that's appropriate
19:12:51 [JeniT]
s/aj udiciously/a judiciously/
19:13:03 [jar]
ht: If it doesn't work, we jave a basis for creating a new effort , community group maybe
19:13:04 [noah]
I heard Henry say that the time to move to a community process is >after< feedback is received from Jonathan's call
19:13:35 [jar]
yes
19:13:45 [ht]
Noah is correct
19:13:57 [ht]
Step 1: Call for change proposals
19:14:39 [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
19:14:51 [ht]
That's just my memory of what JAR already proposed
19:15:19 [jar]
noah: Any objections to proceeding as planned? … Seems not.
19:15:22 [ht]
IOW, I'm happy for JAR to go ahead and Call for Proposals
19:15:33 [Zakim]
-ht
19:15:38 [jar]
noah: JAR, go ahead and publish the call.
19:17:38 [jar]
(discussion of agenda)
19:17:49 [jar]
topic: Design of APIs for Web Applications
19:17:59 [jar]
started 2nd Feb (see agenda)
19:18:04 [noah]
Discussion on 2 February: http://www.w3.org/2001/tag/2012/02/02-minutes#item08
19:19:19 [noah]
Proposal from Robin to expand the scope: http://www.w3.org/2001/tag/2012/02/02-minutes#item08
19:19:32 [jar]
rb: Audience. People *currently* writing specs?
19:19:35 [noah]
Proposal from Robin to expand the scope: http://lists.w3.org/Archives/Public/www-tag/2012Feb/0021.html
19:19:54 [JeniT]
q+ to encourage the TAG to let Robin work on this
19:19:54 [noah]
Draft product page from robin: http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
19:20:28 [noah]
From the draft product page:
19:20:31 [noah]
"This covers multiple related approaches to preserving users' privacy:
19:20:38 [noah]
* User-mediated enumeration.
19:20:44 [jar]
rb: The initial product page was focused on miniization. I broadened it slightly, not to boil ocean, but just to include fingerprinting. The two are hard to separate
19:21:00 [noah]
* Device-triggered access.
19:21:07 [jar]
… Min only looks at information you give away when returning from method call, as opposed to info you give away right at the start
19:21:07 [noah]
* API minimisation
19:21:20 [masinter]
remember GeoLocation vs. GeoPriv controversy over API design that wasn't miniimization
19:21:35 [masinter]
q+ to remind about GeoLocation vs. GeoPriv
19:21:39 [jar]
… There are 4 WGs looking at fingerprinting. I don't think it's a huge broadening, just more coherent, and more relevant
19:21:50 [noah]
ack next
19:21:51 [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"
19:21:51 [Zakim]
... critique
19:22:04 [noah]
ack next
19:22:06 [Zakim]
JeniT, you wanted to encourage the TAG to let Robin work on this
19:22:40 [masinter]
one of the question about SPDY and privacy was whether use of SSL improved ability to fingerprinting
19:22:41 [jar]
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
19:22:43 [noah]
ack next
19:22:44 [Zakim]
masinter, you wanted to remind about GeoLocation vs. GeoPriv
19:23:45 [jar]
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.
19:23:49 [masinter]
it's an API design issue
19:24:27 [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
19:24:29 [jar]
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
19:25:11 [jar]
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
19:25:17 [noah]
q?
19:25:58 [jar]
noah: SOunds like people are supportive of Robin's plan. Can we look at product page?
19:26:11 [masinter]
topics and products should be defined by their center rather than their boundaries
19:26:11 [jar]
http://www.w3.org/2001/tag/products/apiminimization.html
19:26:54 [masinter]
Note that the success criteria don't erquire 'minimization' in the solution space
19:27:08 [masinter]
s/erquire/explicitly require/
19:27:16 [darobin]
http://www.w3.org/2001/tag/doc/APIMinimization.html
19:27:16 [jar]
http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
19:27:36 [jar]
noah: We could treat this as a new document with new schedule
19:27:52 [jar]
rb: Lots of good stuff in what Dan did.
19:28:17 [jar]
noah: You're proposing a draft for the April F2F.
19:28:47 [masinter]
i'm willing to review other people's documents
19:29:20 [masinter]
s/to review/to do early review of/
19:29:39 [jar]
noah: Propose to adopt RB's draft
19:29:59 [noah]
. PROPOSED RESOLUTION: The TAG agrees to work on a "product" on Privacy by Design as described in http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
19:30:21 [noah]
RESOLUTION: The TAG agrees to work on a "product" on Privacy by Design as described in http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
19:30:25 [noah]
Agreed without dissent
19:30:37 [noah]
http://www.w3.org/2001/tag/products/
19:31:14 [jar]
noah: Increase priority after seeing next draft?
19:31:20 [jar]
(maybe)
19:31:28 [noah]
NM: We will keep this as "Other Active Project" for this round, hope to move it up.
19:31:36 [Zakim]
-Ashok
19:31:56 [jar]
ADJOURNED
19:32:01 [Zakim]
-darobin
19:32:03 [Zakim]
-noah
19:32:04 [Zakim]
-Yves
19:32:06 [Zakim]
-Masinter
19:32:06 [Zakim]
-JeniT
19:32:08 [Zakim]
-plinss
19:32:09 [jar]
rrsagent, pointer
19:32:09 [RRSAgent]
See http://www.w3.org/2012/02/16-tagmem-irc#T19-32-09
19:32:12 [noah]
Robin, you still here?
19:32:24 [darobin]
noah: for a few minutes yes
19:32:34 [noah]
Suggest you clean up the product page, and when the content is right, let me know and I'll point it from the main page, make sure all dated URIs are right, etc.
19:32:40 [noah]
OK?
19:33:15 [jar]
agenda: http://www.w3.org/2001/tag/2012/02/16-agenda
19:33:16 [noah]
If it's ready to go now, just say so (e.g. we can take out the orange text?)
19:33:52 [darobin]
noah: yes, that sounds good
19:34:05 [darobin]
we can take out the orange text, it was from the existing version
19:34:22 [darobin]
I don't think that we need to define "privacy characteristics" better at this point
19:34:52 [darobin]
I mean it would be nice to have firm metrics on privacy, but that's a broadening of the scope that could swallow up the entire TAG for a decade or two :)
19:35:07 [darobin]
want me to kill the orange?
19:37:09 [Zakim]
disconnecting the lone participant, Jonathan_Rees, in TAG_Weekly()1:00PM
19:37:12 [Zakim]
TAG_Weekly()1:00PM has ended
19:37:12 [Zakim]
Attendees were Masinter, plinss, Ashok, noah, Jonathan_Rees, Yves, ht, darobin, JeniT
19:37:38 [darobin]
noah: I've committed a slightly cleaned up version
19:38:15 [noah]
OK, I've also just cleaned up entry in http://www.w3.org/2001/tag/products/ Is it OK I hope?
19:38:21 [darobin]
I have to head out now — don't hesitate to email me if I can help
19:38:32 [darobin]
LGTM!
19:38:58 [noah]
OK
19:39:03 [noah]
Same URI?
19:39:21 [darobin]
yeah, let's make it one of those cool URIs I've heard about
19:40:01 [noah]
OK, I'll check in the undated copy.
19:40:05 [darobin]
thanks a lot
19:40:13 [timbl]
timbl has joined #tagmem
19:40:14 [darobin]
I hope the music wasn't too disruptive
19:40:26 [darobin]
one of the great things with this office is that it's lively
19:40:27 [noah]
dibe
19:40:30 [noah]
done
19:40:42 [noah]
http://www.w3.org/2001/tag/products/apiminimization.html
19:40:50 [darobin]
but this does indeed occasionally entail that a wine tasting event takes place during a TAG call
19:41:04 [noah]
Hmm, some funky css in the sizing of the dated links at the top. OK, you can bring the wine to the F2F.
19:41:18 [darobin]
looks good
19:41:25 [darobin]
mmm, yes, CSS issue
19:41:33 [darobin]
I'm afraid they will drink it all
19:42:18 [darobin]
lemme fix the CSS
19:49:27 [noah]
argh... NO!
19:49:33 [noah]
I got it, but we're getting merge conflicts.
19:49:46 [noah]
Just let me do it, as I've got a verison that's like all the others. Thanks.
19:50:34 [noah]
Done, take a look
20:16:18 [masinter]
masinter has joined #tagmem
21:45:48 [Zakim]
Zakim has left #tagmem
23:33:08 [jar]
jar has joined #tagmem