IRC log of tagmem on 2012-06-12

Timestamps are in UTC.

13:08:34 [RRSAgent]
RRSAgent has joined #tagmem
13:08:34 [RRSAgent]
logging to http://www.w3.org/2012/06/12-tagmem-irc
13:08:36 [trackbot]
RRSAgent, make logs public
13:08:36 [Zakim]
Zakim has joined #tagmem
13:08:38 [trackbot]
Zakim, this will be TAG
13:08:38 [Zakim]
ok, trackbot, I see TAG_f2f()8:00AM already started
13:08:39 [trackbot]
Meeting: Technical Architecture Group Teleconference
13:08:39 [trackbot]
Date: 12 June 2012
13:11:30 [ht]
Meeting: TAG f2f
13:11:37 [ht]
ScribeNick: ht
13:11:42 [ht]
Scribe: Henry S. Thompson
13:11:48 [ht]
Chair: Noah Mendelsohn
13:12:00 [ht]
Agenda: http://www.w3.org/2001/tag/2012/06/12-agenda
13:12:05 [masinter]
zakim, who's here?
13:12:05 [Zakim]
On the phone I see +1.617.715.aaaa
13:12:11 [Zakim]
On IRC I see RRSAgent, noah, Ashok, masinter, ht, jar, JeniT, darobin, trackbot, Yves, plinss
13:12:48 [Zakim]
+Yves
13:13:19 [ht]
RRSAgent, log?
13:13:19 [RRSAgent]
I'm logging. Sorry, nothing found for 'log'
13:14:58 [timbl]
timbl has joined #tagmem
13:16:25 [Zakim]
+ +33.1.43.14.aabb
13:17:00 [darobin]
Zakim, aabb is me
13:17:00 [Zakim]
+darobin; got it
13:21:36 [Norm]
Norm has joined #tagmem
13:23:06 [Norm]
noah?
13:23:50 [Norm]
Yes. Let's say I can do that and I'll try to get something ready by then
13:23:52 [darobin]
darobin has joined #tagmem
13:24:05 [ht]
NM: Minutes of 24/5?
13:24:08 [Norm]
I'll try to send some sort of summary today, though I'm in a tight spot work wise
13:24:41 [Norm]
Sure thing, JeniT. Sorry I can't be there with you all.
13:25:22 [ht]
NM: RESOLUTION: Minutes of 24/5 at http://www.w3.org/2001/tag/2012/05/24-minutes approved
13:25:33 [Norm]
I did. I'll get some Rum at duty free in LHR and make them at Summer School, ok?
13:26:01 [ht]
Topic: Privacy by Design in APIs for Web Applications
13:26:10 [noah]
Work plan not approved: http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
13:26:17 [ht]
NM: I believe we do not yet have an approved workplan for this
13:26:46 [ht]
RB: Correct
13:26:53 [ht]
RB: Not sure that's the latest draft
13:27:00 [darobin]
http://www.w3.org/2001/tag/products/apiminimization.html
13:27:14 [masinter]
that one isn't dated
13:27:23 [masinter]
oh it is at bottom kind of
13:28:14 [ht]
RB: I'll walk us through the changes
13:28:30 [ht]
... since Nice f2f
13:28:50 [darobin]
http://darobin.github.com/api-design-privacy/api-design-privacy.html
13:29:27 [plinss]
http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis-2012-06-06.html
13:29:41 [masinter]
http://tools.ietf.org/id/draft-hansen-privacy-terminology-00.html has been updated
13:30:12 [ht]
RB: Feedback at f2f and from others have led to changes
13:30:23 [masinter]
http://tools.ietf.org/id/draft-iab-privacy-terminology-01.html is latest draft
13:30:29 [ht]
... It is trying to address two communities which is tricky
13:30:45 [ht]
... The privacy c'ty and the API creators
13:31:01 [ht]
RB: A lot of the feedback was on providing more background
13:31:26 [ht]
... So I've reworked the intro wrt scope, also added a section on that specifically
13:31:45 [ht]
... To be clear about the _small_ part of the privacy space we are targetting
13:32:10 [ht]
RB: This is in contrast to a lot of other privacy work which IMO has too large a scope
13:32:32 [ht]
RB: So _just_ APIs, and _just_ privacy perspective on APIs
13:32:42 [noah]
q?
13:32:53 [darobin]
darobin has joined #tagmem
13:33:20 [ht]
AM: When you talk about apps later on, you talk about how _apps_ ought to be written -- that's not quite just APIs, is it? It's about how you write the app so as not to access stuff you shouldn't
13:33:40 [ht]
... Aren't you going to get the response "I'll write my app the way I want to"
13:33:50 [ht]
RB: Not sure I understand the distinction
13:33:54 [masinter]
there is another design pattern for APIs which is that APIs which communicate information that's personal should include a redistribution policy (3rd-party usable? timeouts?)
13:34:19 [ht]
RB: In the other document . . .
13:34:32 [ht]
AM: No, in this one, at the end
13:34:50 [masinter]
perhaps there are other design patterns, like origin, which creates sandboxes
13:34:56 [ht]
RB: This doc. is only aimed at API designers, not app authors.
13:35:30 [jar]
q+ jar to unpack "malicious"
13:35:53 [ht]
NM: Maybe the same point? When you mentioned Saltser & Schroeder, I thought I understood -- they say the API strictly limits what non-privileged apps, but tells you how you can do a lot non-the-less.
13:36:09 [ht]
NM: But in their case they assume that those limits are enforced.
13:36:44 [masinter]
DNT is a policy-transmission API
13:36:59 [ht]
... Whereas in what you've written you focus on partitioning the API into individual pieces, w/o talking (much?) about access control _to_ those pieces
13:37:03 [masinter]
I'm taking the view that 'API' and 'network protocol' isn't that different
13:37:17 [noah]
q?
13:37:40 [ht]
RB: Granularity is only one part of the overall approach
13:37:49 [ht]
... That's in the minimization section
13:38:11 [ht]
RB: In the other parts, there is dicussion about privilege separation
13:38:40 [ht]
... So e.g. in the vibration API, it fails w/o saying that's because there is none, so not exposing that information
13:38:53 [noah]
My concern is mainly about the minimization part, and the Schroeder reference in that context
13:38:58 [ht]
RB: Granularity allows easy exposure to the user of what's being accessed/required/used
13:39:09 [masinter]
http://tools.ietf.org/html/draft-iab-privacy-considerations-02 should be background, why is this document so different a context?
13:39:25 [Ashok]
q?
13:39:28 [noah]
I'm saying you need to make clearer that if the app asks for lots of information, the user >will< be told that it's happening and have a chance to say no
13:39:38 [masinter]
design APIs so that it's hard to write buggy apps
13:39:51 [Ashok]
q+
13:39:51 [ht]
... If the app asks for every part of a contacts DB, then the user knows some serious problem might be there, whereas if it only asks for first-name and email address, that sounds like a reasonable request
13:40:03 [noah]
ack next
13:40:05 [Zakim]
jar, you wanted to unpack "malicious"
13:40:12 [masinter]
q+ to give feedback
13:40:34 [ht]
JAR: I have said this before and heard no pushback -- there's a difference between security and privacy
13:40:58 [ht]
... The purpose of minimization is not to provide a security mechanism
13:41:06 [ht]
... But to reduce temptation
13:41:23 [timbl]
q?
13:41:30 [ht]
... It's not that I don't trust you, but if I give you too much information you may be tempted to use more than you need
13:41:46 [ht]
... Removing possible sources of temptation
13:42:01 [noah]
I hear JAR saying that enforcing access controls is a security mechansim only, not privacy. I'm not convinced that's the best use of terminology.
13:42:04 [ht]
TBL: Temptation or attack
13:42:12 [ht]
s/attack/attack?/
13:42:36 [noah]
If I'm enforcing the limit to protect someone's privacy, then it's a privacy mechanism. If I'm doing it to preserve the integrity of the OS (e.g. not disclosing the root password), then it's a security mechanism.
13:42:57 [masinter]
http://tools.ietf.org/html/draft-iab-privacy-considerations-02#page-5
13:42:58 [ht]
JAR: If you ask if you can borrow a book, and lay the book on the table and put a $20 next to it, is it an attack if you take the $20?
13:43:02 [masinter]
q?
13:43:26 [ht]
JAR: policy, "nothing there to protect" [scribe missed]
13:43:41 [noah]
Now I sort of get it a bit, but I think minimization affects privacy too, e.g. to minimize risk of unintentional loss.
13:43:57 [noah]
ack next
13:44:13 [ht]
JAR: The word "malicious" appears in the document, which puts people in the security mindset, and that's not appropriate for this document or its goals
13:44:18 [darobin]
q+ to ask that we not do the privacy/security debate all over again
13:45:13 [ht]
AM: Section 4.1, example, "discover lots of stuff about each mouse" -- what are we going to _do_ about this
13:45:19 [jar]
the risk is of unintended use of information that is provided for a particular purpose. I wouldn't call that an "attack" - connotations are wrong - it's "yielding to temptation"
13:45:42 [ht]
AM: Where in the API can anything prevent/signal/call attention to this
13:45:52 [ht]
s/this/this?/
13:46:22 [ht]
RB: This is an anti-pattern -- don't do this -- it's appeared in lots of apps in various ways
13:47:03 [ht]
... Recent e.g. mouse APIs have been designed so that this isn't possible anymore
13:47:57 [ht]
RB: Even if an app needs info about how many e.g. game controllers you have, you have to be using them for them to be exposed/counted
13:48:27 [ht]
AM: So the API won't support getAllMice()?
13:48:29 [masinter]
I have three points: background & terminology; protocol and APIs equivalence; missing design patterns
13:48:34 [darobin]
q?
13:48:40 [noah]
ack next
13:48:41 [ht]
RB: That information won't be available if the API is designed right
13:48:42 [Zakim]
masinter, you wanted to give feedback
13:49:20 [noah]
There's a new version of http://tools.ietf.org/id/draft-hansen-privacy-terminology-00.html
13:49:30 [ht]
LM: I do see a reference to Hannes's document -- there's a newer version, which is now an IAB [???]
13:49:33 [noah]
s/There/Larry says there/
13:50:41 [ht]
RB: I spoke with Christine ??, and then with Hannes and others, and they said they are actively developing it, with terminology changes, so I'm waiting to hear from them about when it stabilizes, and then I'll reference it and adopt the terms
13:50:45 [masinter]
http://tools.ietf.org/html/draft-iab-privacy-considerations-02#page-5
13:51:21 [ht]
LM: There's also a draft about privacy considerations more generally
13:51:23 [timbl]
(Fascnating: http://tools.ietf.org/html/draft-iab-privacy-considerations-99 redirects to http://tools.ietf.org/html/draft-iab-privacy-considerations-02 !)
13:52:04 [darobin]
q+ to point out that I think there's a logical jump in Larry's protocol <-> API idea
13:52:12 [ht]
LM: I think there's a near-equivalence between privacy wrt protocols and privacy wrt APIs, so minimization, which is discussed in that draft
13:52:47 [ht]
LM: Also, I note that this doc talks about threats and attacks, both wrt privacy and wrt security
13:53:12 [masinter]
the terminology uses "threat" and "attack" but in different context
13:53:42 [noah]
NM: I heard Larry say that the IAB? document talks about attacks against system security, and attacks on users' privacy. That seems exactly right to me.
13:54:09 [darobin]
q+ to point out that DNT is orthogonal to API design, and that GeoPriv led to a catastrophic failure in communication between parties
13:54:09 [ht]
LM: Given that framework, there are various design pattern -- GeoPriv e.g. increases the API to _include_ policy information, particulary regarding redistribution
13:54:31 [ht]
LM: Similarly the Do Not Track header is a policy statement
13:54:37 [jar]
terminology quibble I guess: I would put defense against technical attacks under the "security" banner, and reserve "privacy" for non-security-related concerns. making sure information is *unavailable* to an attacker is a security issue (a particular kind of privacy issue, sometimes)
13:55:09 [noah]
q?
13:55:12 [ht]
LM: [earlier] The protocol/API parallel reminds us that what you _do_ with what you get is part of the equation
13:55:25 [noah]
ack next
13:55:27 [Zakim]
darobin, you wanted to ask that we not do the privacy/security debate all over again and to point out that I think there's a logical jump in Larry's protocol <-> API idea and to
13:55:27 [Zakim]
... point out that DNT is orthogonal to API design, and that GeoPriv led to a catastrophic failure in communication between parties
13:57:01 [ht]
RB: Wrt JAR's comments about privacy/security and vocabulary, e.g. "threat" -- we used to argue this in a section that talked about the commonality, when bad things may happen to the user
13:57:30 [ht]
... but people argued about that, and said we needed references, so we took it out
13:58:02 [ht]
LM: I at least pushed back on the use of a common vocabulary, not that they were compleetely separate
13:58:30 [jar]
I think there's a Venn diagram, with bins (1) privacy not security, (2) privacy and security, (3) security not privacy
13:58:31 [ht]
NM: I heard you try to avoid making that distinction and focus on the doc.
13:59:03 [ht]
RB: I agree there's an issue, and an ongoing discussion, but for _this_ document we're clearly in the intersection, so the problem doesn't arise
13:59:29 [ht]
LM: My argument is about vocabulary, not about scope
13:59:54 [ht]
LM: I don't mind limiting the scope, but I do care that we don't invent new vocabulary
14:00:07 [ht]
... We should use "threat", which is what the IAB use
14:00:19 [ht]
RB: I just don't want to do that until they stabilize
14:00:46 [ht]
... They've already said changes are coming
14:00:48 [ht]
LM: OK
14:01:03 [ht]
NM: JAR, does that address your problem?
14:01:35 [masinter]
sandboxing
14:01:37 [ht]
JAR: If you are talking about privacy, and you are _not_ talking about policy, that seems odd, but maybe you just need to change the title/make this clear
14:01:40 [Ashok]
q+
14:01:49 [darobin]
http://www.w3.org/2012/05/sysapps-wg-charter.html
14:01:54 [ht]
JAR: And the other think that's odd is the absence of discussion about secure Javascript
14:01:55 [masinter]
policy and sandboxing are missing
14:02:37 [ht]
RB: Yes, of course if you have a security hole privacy attacks may be enabled, but that doesn't affect API design
14:03:05 [ht]
... That is, I won't expect any change to an API if you were worried about security attacks
14:03:11 [ht]
s/attackes/holes/
14:03:17 [ht]
JAR: Not clear to me that's true
14:03:19 [masinter]
Robin, could you say who on IAB told you that we shouldn't reference the IAB documents for terminology and privacy considerations?
14:03:33 [masinter]
I'd like to follow up
14:03:58 [ht]
JAR: Imagine someone wanting to learn about privacy by design in Javascript APIs, and thinks this document will tell them what they need -- that would be wrong
14:04:07 [ht]
NM: Change scope, or title?
14:04:29 [ht]
JAR: Title, I think, plus some references to what else they need to know
14:05:17 [ht]
JAR: I need to review the Scope section
14:05:22 [masinter]
Is PING coming up with their own terminology document?
14:05:44 [ht]
NM: Would you, RB, be able to add some pointers?
14:05:57 [ht]
RB: Not sure I understand what's wanted well enough, no
14:06:12 [jar]
q?
14:06:13 [masinter]
q?
14:06:14 [masinter]
q+
14:06:26 [ht]
RB: But if JAR can help, I'm happy to work to improve things in that area
14:06:33 [ht]
ack Yves
14:07:23 [ht]
YL: The focus on unwanted data access is both privacy and security, w/o claiming that that's all of either topic
14:07:58 [ht]
YL: But the fingerprinting part isn't part of API design I don't think
14:08:31 [darobin]
q+ my identity is *also* information I don't want to give access to
14:08:36 [ht]
YL: So I'd like the document to focus only on the not exposing unwanted-to-be-exposed data
14:08:38 [darobin]
q+ to say my identity is *also* information I don't want to give access to
14:08:42 [ht]
q- Ashok
14:08:46 [jar]
if the document is how to design APIs with security characteristics that support privacy goals, then there ought to be a hint in the title that this is the case; or, alternatively, a pointer in the intro that say "if you want to learn about other aspects of privacy by design, read X"
14:08:47 [masinter]
the "privacy considerations" document is more than terminology, and also applicable.
14:09:36 [ht]
AM: We thrashed on privacy for a while and only agreed to tackle this at all when DA proposed this very narrow topic
14:09:37 [masinter]
if this is a topic for PING, should the TAG wait until IAB and PING converge?
14:09:59 [ht]
AM: So I'm worried that JAR's concerns are widening things again
14:10:16 [masinter]
and what about other design patterns not covered?
14:10:30 [Yves]
robin, if you want to stop fingerprinting, you probably need more than api minization, but more policies, and that is not the same scope
14:10:34 [ht]
AM: I liked the old "Data Minimization" title
14:10:41 [darobin]
actually the previous version of the product page that broadened the scope was approved IIRC
14:11:06 [ht]
NM: But when RB took on the document, he did so on the basis of expanding the scope a bit
14:11:21 [ht]
... and that title reflects that
14:11:46 [masinter]
http://tools.ietf.org/html/draft-iab-privacy-considerations-02#section-4.1 is "Data Minimization"
14:11:46 [darobin]
Yves, yes, you can't use just section 4.4 — you mostly need sections 4.1-4.3 ;)
14:12:09 [masinter]
Data minimization is comprised of a number of mutually exclusive sub-goals:
14:12:09 [masinter]
14:12:28 [ht]
AB: I would recommend going back to the original scope, because then we can publish more quickly
14:12:35 [masinter]
q?
14:12:38 [jar]
q?
14:12:52 [Yves]
darobin: not only
14:13:41 [darobin]
Yves, what else do you need when designing new APIs (I'm not talking about handling the existing mess)
14:13:52 [noah]
noah has joined #tagmem
14:13:53 [ht]
LM: [summarizes IAB doc't on DM]
14:14:05 [ht]
LM: I think we should collaborate with this
14:14:06 [Yves]
I mean that you might fingerprint by merely using multiple apis
14:14:20 [ht]
LM: If they're not ready to collaborate, we should wait until they are
14:14:39 [jar]
IF policy transmission is the only non-security privacy-by-design technique we know of, then it would suffice to just add a short section on policy transmission. then the title would match the scope…
14:14:59 [ht]
AM: But we, and they, having been working for a long time
14:15:15 [darobin]
jar, how does policy transmission affect API design?
14:15:23 [Yves]
so you need specific policies to avoid mixing that information to generate accurate identifiers
14:15:26 [ht]
LM: They are talking about protocols, we are talking about APIs, so there's a difference
14:15:58 [jar]
to transmit a policy, the API has to provide a way to transmit it (as a parameter). you already talk about this in the document
14:16:07 [darobin]
Yves, if individual APIs do not yield identifying information, having more of them won't help identify more I would think
14:16:18 [noah]
q?
14:16:24 [noah]
ack masinter
14:16:45 [darobin]
jar, that's known as the GeoPriv anti-pattern :)
14:16:51 [Yves]
darobin, it depends on the level of fuzziness ;)
14:16:54 [ht]
LM: There is a trust difference, certainly -- I might trust an app, and install it, more than I trust "the net" and thus not want stuff to go over the web that I would let an app see on my machine
14:17:22 [ht]
LM: But then of course things such as Kindle Fire muddy the water
14:17:23 [jar]
fine if it's an anti-pattern. discussion of it is in the scope implied by the title. even if you want to argue against it
14:17:42 [ht]
s/water/waters/
14:17:44 [darobin]
jar, well, the primary argument against it is that politically it won't happen
14:17:57 [darobin]
but it's true that I could include a section on antipatterns
14:18:06 [darobin]
q?
14:18:17 [jar]
but it *is* happening - as DNT
14:18:36 [darobin]
which is 100% orthogonal to API design — not the pattern you describe
14:18:56 [jar]
disagree. it's policy transmission.
14:19:02 [ht]
NM: Should we add something to the draft about this connection, at least to signal it exists and aim for cooperation
14:19:04 [ht]
LM: Yes
14:19:12 [Yves]
antipatterns would be a good idea indeed
14:19:22 [darobin]
jar, it changes *nothing* to how you design the API
14:19:26 [ht]
RB: That sounds good to me, yes
14:20:03 [jar]
any API that's involved in implementing DNT policy will have to have a way to transmit the DNT policy
14:20:22 [darobin]
jar, JS APIs won't even touch DNT
14:20:22 [darobin]
ack me
14:20:22 [Zakim]
darobin, you wanted to say my identity is *also* information I don't want to give access to
14:20:45 [ht]
NN: LM said "There are concerns wrt protocols and privacy, there are concerns wrt APIs and privacy. We're working on APIs, IETF are working on protocols, we will collaborate and try to converge at least on terminology going forward"
14:21:06 [darobin]
ACTION: Robin to incorporate into Privacy document "There are concerns wrt protocols and privacy, there are concerns wrt APIs and privacy. We're working on APIs, IETF are working on protocols, we will collaborate and try to converge at least on terminology going forward"
14:21:06 [trackbot]
Created ACTION-713 - Incorporate into Privacy document "There are concerns wrt protocols and privacy, there are concerns wrt APIs and privacy. We're working on APIs, IETF are working on protocols, we will collaborate and try to converge at least on terminology going forward" [on Robin Berjon - due 2012-06-19].
14:21:07 [noah]
s/NN/NM/
14:21:14 [jar]
isn't DNT binding on ajax?
14:21:23 [darobin]
Ajax isn't an JS API
14:21:25 [darobin]
it's network
14:21:37 [jar]
XHR
14:21:37 [noah]
It's not just "we are working on", it's "this document focusses primarily on APIs, they are working on protocols, we intend to collaborate with them on points of overlap"
14:21:43 [ht]
AM: This will never finish if we do this
14:22:21 [ht]
NM: We're only talking about trying to be consistent, not trying to have a jointly agreed outcome
14:22:28 [ht]
LM: Who is Christine?
14:22:49 [noah]
We are, IMO, not committing to wait for any particular progress from those doing protocols, just saying we will attempt to coordinate, and we'll see where that leads on both content and schedules.
14:23:37 [Ashok]
Christine Runnegar
14:23:39 [ht]
RB: I've been emailing with Hannes T and Alicia ?, and Christine ?? who is co-chair of the Privacy Interest Group
14:23:46 [masinter]
q+ to ask about whether this should be done by PING?
14:23:59 [darobin]
s/Alicia/Alissa/
14:24:22 [ht]
RB: That's the W3C Privacy IG, and Alissa is on that group, so that seems like a good place to have this discussion
14:24:28 [masinter]
s/Hannes T/Hannes Tschofenig/
14:24:30 [darobin]
jar, XHR is something you use to talk to something else on the network — and the JS certainly won't be allowed to set DNT
14:25:05 [ht]
NM: So I'd like to turn to the process by which we get this published as a PWD
14:25:27 [ht]
LM: Shouldn't this be being produced by the Privacy IG?
14:25:42 [ht]
AM: They're an IG, and they have 1 call per month
14:26:04 [ht]
RB: It's early days for them, they aren't ready to take this one
14:26:52 [ht]
HST: If they ever fork a WG, maybe we park our WD based on calling it input into their work
14:27:41 [ht]
LM: Could NM at least officially tell them we are doing this
14:27:51 [ht]
NM: Sure, if we agree to go ahead
14:28:02 [masinter]
s/tell them/ask them if it is ok that/
14:28:21 [jar]
APIs and protocols are very similar, and over time become more and more so. e.g. in SES they're hard to distinguish. people designing one will always eventually design the other. historical experience is that they always converge. … in any case if you're right, it would help me to find an argument in a document called "privacy by design in javascript APIs", or a reference. it's in the scope set by the title
14:28:51 [masinter]
i don't think the TAG should take this on if there's a working group chartered to do this
14:28:55 [masinter]
q+
14:28:57 [masinter]
q?
14:29:05 [ht]
.ACTION: NM to email Christine ? that we are about to publish this doc't and offering to coordinate with them on who does what
14:29:30 [ht]
LM: I don't think we should be doing this
14:29:44 [ht]
... I think a group dedicated to working on privacy should do this
14:29:59 [ht]
... I'm willing for the TAG to work on it until there is such a group
14:30:06 [ht]
... but only until then
14:30:46 [ht]
q- masinter
14:31:00 [masinter]
this is a small part of "how to design for privacy"
14:31:38 [darobin]
[if the TAG were to drop this document, it would likely get published in DAP in cooperation with PING]
14:31:54 [ht]
LM: The W3C needs to do the whole thing, not just this
14:32:06 [jar]
prefixing the title with the word "some" might address my concern
14:32:06 [ht]
... The whole thing is _very_ big
14:32:17 [masinter]
the tag can't do the whole thing
14:32:30 [masinter]
i think this is something we can START on
14:32:37 [jar]
q?
14:32:50 [jar]
q+ jar to suggest "some"
14:32:58 [ht]
AM: I thought we needed a victory in this space, so when we found a nice well-delimited task, we agreed to go ahead on it -- it's a step forward
14:33:06 [masinter]
maybe publish as a NOTE saying that we looked at a little piece of the space and more should be done, because our intent isn't to take on the whole thing.
14:33:36 [masinter]
q?
14:33:39 [ht]
q- jar
14:34:17 [darobin]
jar, I am not aware of a single "patterns" document that claims to cover all patterns?
14:34:18 [ht]
JAR: If we changed the title to "Some Patterns for Privacy. . .", that would help me -- LM?
14:34:39 [ht]
LM: Yes, along with a preface about where this fits, as a Note
14:34:54 [darobin]
+1 to Jeni!
14:35:18 [ht]
JT: More important to publish now than discuss where it fits indefinitely
14:35:20 [Ashok]
+1
14:35:43 [masinter]
leadership is the skill of getting people to follow. i'm trying to figure out how the TAG can lead. Not even 'getting it right'
14:35:52 [ht]
NM: LM you surprised me
14:36:18 [ht]
LM: The TAG should lead, which means getting others to follow
14:36:39 [masinter]
i don't think what we have is a complete set of design patterns for privacy
14:36:52 [ht]
NM: Is this publish and quit, or are we aiming for a good job, which we will edit in response to feedback
14:37:38 [ht]
LM: What we have doesn't cover all the things in might, including sandboxing, secure Javascript and policy transmission
14:38:04 [ht]
... so we don't claim it's exhaustive
14:38:29 [ht]
NM: OK, so do we publish it to get feedback and promise to revise, etc.
14:38:47 [ht]
... or do we expect to just hand it off and stop there?
14:39:38 [ht]
NM: Personally, I agree to bound and label the scope, but publish as a PWD because we want to get feedback and improve as a result.
14:40:12 [darobin]
FWIW, I think that there are only two options forward: FPWD and keep going, or pass it to another group
14:41:05 [masinter]
i have a low barrier for FPWD as long as the disclaimer
14:42:11 [ht]
NM: Title change, e.g. "Some Patterns. . .", so additional material about relation with protocols, FPWD, starting down REC track -- is that what we are saying?
14:42:59 [ht]
LM: Yes, but conditional on a) IAB ref; b) not all of privacy; c) belongs elsewhere.
14:44:05 [masinter]
to be useful, this has to be only one of a suite of documents about privacy
14:44:56 [ht]
NM: We have pulled things off REC track, but that sends at best a mixed message, I don't want to go ahead without a commitment that our best guess is that we want to take this to REC if we can
14:45:01 [JeniT]
masinter, that's true, but we don't get to do a suite of documents without starting somewhere
14:46:06 [ht]
HST: I don't agree with LM's caveat (c) -- we are committing to do this
14:46:39 [ht]
PL: I think there should be a WG producing RECs on privacy. If there was, they should be doing this. But there isn't. So we should.
14:47:04 [darobin]
[especially since this document is not at all about building privacy aware applications at all]
14:47:09 [ht]
LM: A world in which this is the only W3C doc't on Privacy in apps would not be a good one.
14:47:48 [ht]
NM: Agreed, but not by putting that language in this document.
14:48:28 [ht]
LM: So where _do_ we say we think there should be "a WG producing RECs on privacy".
14:48:38 [ht]
s/"./"?/
14:49:46 [ht]
NM: We can talk about how to take this forward elsewhere, can we just publish the document?
14:50:06 [ht]
PL: Can we put this on the product page
14:50:07 [timbl]
Poposal: ACTION noah contact JJ to pass on the message that the TAG thnks that W3C should have a working group working on Privacy
14:50:28 [darobin]
darobin has joined #tagmem
14:51:25 [jar]
this is an argument over what gets written in the 'status' section, right?
14:51:29 [ht]
ack Yves
14:53:57 [ht]
NM: So the product page will only track the narrow document, I will take an action to communicate the larger need
14:54:21 [noah]
. RESOLUTION: the TAG thnks that W3C should have a working group working on Privacy
14:54:45 [masinter]
which should take on as one of its work product to take on this document
14:54:55 [darobin]
note that I think the reason there is an IG on Privacy is so that we can figure out what a WG on Privacy would do (or several)
14:54:58 [Yves]
note that having a WG working on the topic doesn't preclude to publish document that might act (or not) as a seed document
14:57:15 [ht]
. RESOLUTION: The TAG thinks the W3C should have a working group working on Privacy, with scope to include the area covered by the "Some Patterns..." document currently under development in the TAG
14:57:26 [masinter]
+1
14:57:47 [noah]
RESOLUTION: The TAG thinks the W3C should have a working group working on Privacy, with scope to include the area covered by the "Some Patterns..." document currently under development in the TAG
14:57:51 [noah]
Passes without dissent
14:58:18 [ht]
ACTION Noah to communicate that tThe TAG thinks the W3C should have a working group working on Privacy, with scope to include the area covered by the "Some Patterns..." document currently under development in the TAG
14:58:18 [ht]
<noah> Passes without dissent
14:58:19 [trackbot]
Created ACTION-714 - Communicate that tThe TAG thinks the W3C should have a working group working on Privacy, with scope to include the area covered by the "Some Patterns..." document currently under development in the TAG [on Noah Mendelsohn - due 2012-06-19].
14:59:00 [timbl_]
timbl_ has joined #tagmem
14:59:10 [ht]
NM: Objections to moving forward with the document?
14:59:12 [ht]
[none]
14:59:27 [ht]
NM: Objections to FPWD on the Web track?
14:59:29 [ht]
[none]
14:59:31 [masinter]
FPWD, doesn't need to say "rec trac"
14:59:43 [ht]
s/Web track/Rec track/
15:00:17 [masinter]
+1 to adding word 'some' to title
15:00:20 [ht]
NM: Add the word "Some"?
15:00:24 [ht]
[no objections]
15:00:24 [noah]
Accepted without objection: add "some" to the title
15:00:35 [darobin]
http://www.w3.org/2001/tag/products/apiminimization.html
15:00:42 [JeniT]
http://www.w3.org/2001/tag/products/apiminimization-2012-06-08.html
15:00:48 [noah]
http://www.w3.org/2001/tag/products/apiminimization-2012-06-08.html
15:01:20 [darobin]
I still wonder if anyone has ever seen a patterns document claiming to exhaustively document all patterns but *shrug*, won't bikeshed :)
15:01:33 [JeniT]
why ever not?
15:02:23 [darobin]
JeniT, they're all about "some patterns" :)
15:02:38 [noah]
HT: Propose replacing "TBD: an approved TAG finding on API Privacy by Design" with disjunction:
15:02:40 [noah]
Either:
15:02:49 [darobin]
jenit, but hey, I think a slightly brighter shade of pink might catch the light better
15:02:56 [noah]
* We publish a document (could be finding, rec, note TBD) -or-
15:03:04 [noah]
* This gets handed over to new privacy group
15:03:25 [darobin]
should the product page make the assumption that a new privacy group will be chartered?
15:03:37 [masinter]
question for product page to include liaison with IAB and PING
15:03:41 [Yves]
might be chartered
15:04:29 [darobin]
Yves, Dan, Robin — who can tell the difference between those frenchmen
15:04:40 [noah]
HT: Prefer not to get into details of handing over and to whom in the product page
15:04:59 [ht]
LM: Adding something about liaison helps clarify our goals
15:05:24 [ht]
LM: We will be commited to trying to resolve any disagreements
15:05:58 [darobin]
s/commited/committed/
15:07:22 [noah]
close ACTION-684
15:07:22 [trackbot]
ACTION-684 Update Privacy by Design in APIs closed
15:07:48 [darobin]
here's the same document as a FPWD :) http://darobin.github.com/api-design-privacy/api-design-privacy.html?specStatus=FPWD
15:08:03 [noah]
ACTION: Robin to prepare draft FPWD of some patterns for privacy in APIs, to be reviewed by TAG and published - Due 2012-06-26
15:08:04 [trackbot]
Created ACTION-715 - prepare draft FPWD of some patterns for privacy in APIs, to be reviewed by TAG and published [on Robin Berjon - due 2012-06-26].
15:08:24 [ht]
NM: Need an action on the PP
15:08:28 [jar]
"patterns for X" to me has the implicature of "all the patterns we know about, or at least a pretty dense sampling". "some patterns for X" doesn't
15:09:25 [darobin]
I really have to leave — sorry
15:09:45 [darobin]
please just give me actions!
15:09:49 [Zakim]
-darobin
15:11:39 [ht]
NM: Is a goal that we initiate further W3C work?
15:11:41 [ht]
LM: Yes
15:11:45 [ht]
NM: Objections?
15:11:48 [noah]
. ACTION: Noah to update privacy product page to indicate a) possible handoff to other group b) liaison with IAB & IETF privacy interest group c) goal to initiate larger activity in privacy
15:12:01 [ht]
[none]
15:12:13 [noah]
ACTION: Noah to update privacy product page to indicate a) possible handoff to other group b) liaison with IAB & IETF privacy interest group c) goal to initiate larger activity in privacy - Due: 2012-07-31
15:12:13 [trackbot]
Created ACTION-716 - Update privacy product page to indicate a) possible handoff to other group b) liaison with IAB & IETF privacy interest group c) goal to initiate larger activity in privacy - Due: 2012-07-31 [on Noah Mendelsohn - due 2012-06-19].
15:12:31 [noah]
ACTION-650?
15:12:31 [trackbot]
ACTION-650 -- Jonathan Rees to review what provenance WG is doing with an eye to application to privacy issues -- due 2012-08-01 -- OPEN
15:12:31 [trackbot]
http://www.w3.org/2001/tag/group/track/actions/650
15:12:58 [noah]
JAR: no need for attention now.
15:24:50 [Ashok]
Ashok has joined #tagmem
15:27:27 [ht]
Topic: ACTION-563: Periodic TAG key issues reports to Jeff Jaffe
15:28:13 [ht]
NM: We will owe an issue update in the autumn to JJ
15:29:12 [noah]
q?
15:29:32 [ht]
LM: Things we the TAG have struggled with:
15:30:07 [ht]
... XML and HTML are on divergent tracks, and they are both important to the W3C
15:30:55 [masinter]
Distributed Extensibility
15:31:53 [masinter]
apps vs. web
15:32:02 [ht]
JAR: How do we frame this for JJ? Our previous message got the response: OK, so what do we do about it?
15:32:03 [masinter]
for mobile
15:32:29 [ht]
NM: We should remember to revisit our last list before we do a new one. . .
15:32:57 [ht]
AM: What if we work back from "What does the W3C want to accomplish?"
15:33:03 [masinter]
boundary between 'web' and 'non-web' for apps?
15:33:22 [ht]
AM: For example, getting more uptake for the Semantic Web
15:33:41 [jar]
semantic web is a means to an end… what's the end?
15:33:58 [ht]
NM: JJ asked for alerts about things happening "out there" that he should be aware of
15:34:35 [ht]
NM: Net neutrality? Installing servers "near the edges"
15:35:34 [ht]
q+ to mention aging/companions/communities
15:35:51 [ht]
TBL: Pushing it, or defining it?
15:36:16 [JeniT]
q+ to raise distributed web applications (eg unhosted)
15:36:18 [ht]
NM: Things which undermine the equality of access on the Web happen all the time
15:36:22 [ht]
TBL: That's a given
15:36:46 [noah]
q?
15:36:49 [ht]
ack ht
15:36:49 [Zakim]
ht, you wanted to mention aging/companions/communities
15:36:50 [jar]
q?
15:37:40 [noah]
HT: Help me get this right... trying to use technology, in some cases Web technology, to deal with changing age demographics in the "developed" world
15:38:12 [noah]
HT: Using Web technology, in particular social Web technology, to address problems especially of older people learning alone.
15:38:36 [noah]
HT: Story about study in UK that death rates could be cut dramatically if those at risk check their feet everyday.
15:38:55 [noah]
HT: Relates to gangreen and diabetes. Old people can't easily see their feet.
15:39:07 [jar]
q+ jar to webp2p , http://cyber.law.harvard.edu/node/5136
15:39:40 [noah]
HT: I'm thinking of communities that are housebound
15:40:05 [masinter]
distance ed
15:40:07 [masinter]
video
15:40:34 [noah]
TBL: Judy has some funding in this area. It's not a new idea, but it is important.
15:40:39 [masinter]
gamification
15:41:02 [masinter]
globalization
15:41:09 [masinter]
i18n isn't good enough
15:41:17 [noah]
ack next
15:41:18 [Zakim]
JeniT, you wanted to raise distributed web applications (eg unhosted)
15:41:20 [masinter]
game-ificaiton
15:43:23 [ht]
JT: Distributed web apps means e.g. getting your app code from one server, but your data from one or more _other_ servers -- known as "unhosted" apps -- so you aren't dependent on any one silo/walled-garden for your data
15:43:53 [ht]
AM: Linked Data Platform (LDP) is _not_ about unhosted data
15:44:10 [ht]
... There target is extending REST to Linked Data
15:44:16 [JeniT]
http://unhosted.org/
15:44:27 [ht]
TBL: Aren't they talking about separating app from data?
15:44:45 [noah]
q?
15:44:53 [ht]
... decoupling provision of stores from provision of apps
15:44:54 [noah]
q+ to ask Jeni a question
15:45:09 [ht]
q+ to raise the remote join question
15:45:44 [ht]
ack noah
15:45:44 [Zakim]
noah, you wanted to ask Jeni a question
15:45:52 [jar]
unhosted is analogous to patient-controlled EHRs
15:46:09 [ht]
NM: Is unhosted like AJAX, a way of thinking about your app?
15:46:56 [ht]
JT: Yes, but also a concrete implementation, which you can import to give access to multiple sources of (encrypted) data
15:47:11 [ht]
NM: So it is AJAX like, with some concrete JS support
15:47:36 [noah]
ack next
15:47:37 [Zakim]
jar, you wanted to webp2p , http://cyber.law.harvard.edu/node/5136
15:48:01 [ht]
JT: Different from mashups is that e.g. Craigs List and google supplied the data for them,
15:48:05 [noah]
q?
15:48:11 [ht]
... whereas unhosted means _you_ supply the data
15:48:36 [ht]
AM: So when you start an app, do you spell out which sources of data to access?
15:48:42 [ht]
JT: I think so, but not sure
15:49:40 [ht]
TBL: So I imagine this as e.g. a version of Doodle which asks you "which [of your data] space do you want this meeting to use?"
15:49:51 [jar]
http://www.mendeley.com/research/indivo-x-developing-fully-substitutable-personally-controlled-health-record-platform/
15:50:02 [masinter]
spaces?
15:50:17 [ht]
... So that we can choose stores for different data parts based on the properties, e.g. privacy, they provide
15:50:27 [masinter]
q+ to give some new topics, disruption of higher ed
15:50:28 [ht]
ack jar
15:50:46 [ht]
JAR: I keep coming back to peer-to-peer -- has it heated up enough?
15:50:48 [masinter]
facebook, identity, "social"
15:50:59 [JeniT]
from unhosted.org: "The web is not as open as it used to be: monopoly platforms formed new proprietary layers on top of it. But we create a better architecture for the web. We break the package deal »you get our app, we get your data« with remoteStorage, a cross-origin storage protocol separating application servers from people's documents."
15:51:11 [ht]
JAR: There's a web-p-to-p mailing list, which has been sort of quiet lately
15:51:26 [noah]
ack next
15:51:28 [Zakim]
ht, you wanted to raise the remote join question
15:51:35 [ht]
JAR: My fantasy is of p-to-p as a backup for the Web when the servers stop working
15:51:43 [jar]
or DNS
15:52:20 [JeniT]
http://www.w3.org/TR/sparql11-federated-query/
15:52:39 [masinter]
does webrtc/rtcweb change skype / connect / webex ?
15:52:50 [noah]
HT: Every 6-18 months I ask... Preamble: I don't want to load all your triples, or sparql to one source...want remote join
15:53:38 [masinter]
"web of video" "hypervideo" ?
15:53:44 [masinter]
just brainstorming
15:54:08 [noah]
...general sense...probably not now
15:54:14 [masinter]
impact / likelihood of action / timeliness
15:54:33 [jar]
ht: Is there anything important happening in this space, that it should get attention?
15:54:53 [masinter]
vertical application spaces with near-term web impact
15:55:11 [jar]
http://tesla.lcs.mit.edu/publications/Papers/sheldon.pdf
15:55:26 [masinter]
http://www.khanacademy.org/
15:55:36 [ht]
TBL: My goal is to have a SPARQL query, as such, and on that basis diagnoses based on a bunch of indices what data sources need to be accessed to get an answer
15:55:45 [masinter]
note "ni:" scheme discussion
15:55:47 [ht]
... and then uses those source to do the remote joing
15:56:07 [ht]
TBL: The second part has been well studied, but the first has not
15:56:18 [noah]
q?
15:56:42 [masinter]
http://tools.ietf.org/html/draft-farrell-decade-ni
15:56:44 [jar]
comment on my scribed comment above re webp2p: the list isn't quiet; rather it's nascent, mostly introductions now, some interesting discussion
15:57:11 [ht]
ack masinter
15:57:11 [Zakim]
masinter, you wanted to give some new topics, disruption of higher ed
15:57:13 [noah]
ack next
15:57:39 [ht]
LM: Verticals with possible disruptive near-term impact: healthcare and higher education
15:57:58 [ht]
... Some threshhold wrt higher education on the web seems to be being crossed
15:58:17 [ht]
... Maybe healthcare
15:58:45 [ht]
LM: RTC Web -- peer-to-peer video is another potential problem area
15:59:01 [ht]
HST: IETF work isn't adequate?
15:59:11 [ht]
LM: I think some things are maybe falling in the gaps. . .
15:59:34 [ht]
... IETF is doing protocols, W3C the APIS, but I'm not sure it's all covered
15:59:47 [jar]
another p2p thing to be aware of might be the ietf decade wg… possible evidence of foment?
15:59:48 [masinter]
move of more things from text => video mean hypervideo
16:00:13 [noah]
HT: What about identity (of people)
16:00:19 [noah]
JAR: W3C hired someone
16:00:30 [jar]
= Wendy
16:01:08 [Zakim]
- +1.617.715.aaaa
16:01:11 [jar]
one question is whether there is coordination between browserid & webid… but i'd be surprised if there weren't
16:01:16 [ht]
NM: Adjourned until 1345
16:01:34 [Zakim]
-Yves
16:01:35 [Zakim]
TAG_f2f()8:00AM has ended
16:01:35 [Zakim]
Attendees were +1.617.715.aaaa, Yves, +33.1.43.14.aabb, darobin
16:05:38 [ht]
Thread on acct: URI scheme: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05957.html
16:49:36 [jar]
jar has joined #tagmem
16:50:12 [JeniT]
JeniT has joined #tagmem
16:52:15 [timbl]
timbl has joined #tagmem
17:09:21 [ht]
ht has joined #tagmem
17:09:43 [ht]
jar, jenit - where are you?
17:09:50 [jar]
8th floor
17:10:11 [ht]
coming
17:47:45 [masinter]
masinter has joined #tagmem
17:48:57 [Ashok]
Ashok has joined #tagmem
17:49:20 [noah]
noah has joined #tagmem
17:50:09 [JeniT]
Scribe: JeniT
17:51:26 [JeniT]
Topic: Quick report from lunchtime ISSUE-57 breakout group
17:51:35 [JeniT]
jar: plan for Thursday's session on ISSUE-57
17:51:49 [JeniT]
... two problems: technical and procedural
17:52:13 [JeniT]
... jar, ht, JeniT & timbl have been exchanging emails behind the scenes
17:52:19 [JeniT]
... we have a rough consensus
17:52:34 [JeniT]
... technical part is to present "parallel properties" idea
17:52:58 [JeniT]
... has been around for 10 years, in some form or another
17:53:21 [JeniT]
... we have thoughts in terms of how to present or sell it, to see it differently
17:53:47 [JeniT]
... procedurally, first is to report back to the community about change proposals
17:53:59 [JeniT]
... then to prepare a document presenting "parallel properties" idea
17:54:04 [JeniT]
... then spin up a community group
17:54:26 [JeniT]
Ashok: if we spin up a CG, is the TAG off the hook
17:54:35 [JeniT]
jar: that's part of the question, it depends on the purpose of the CG
17:54:50 [JeniT]
... if the purpose is to solve the problem, it would require the TAG to have some level of commitment to the group
17:55:05 [JeniT]
... required for continuity for what we've been doing over last couple of months
17:55:12 [JeniT]
... take the draft as a starting point
17:55:31 [JeniT]
... the matrix would be an input to the CG
17:55:46 [JeniT]
noah: what about the other documents you produced? are they still useful points of reference?
17:56:07 [JeniT]
jar: if someone has questions about why particular options were discarded, then yes, but more for that historical purpose
17:56:29 [JeniT]
... easiest thing is to give CG a bibliography, harder to provide an orientation document
17:56:40 [JeniT]
... let the group start meeting, and see if they need it
17:56:56 [JeniT]
noah: we worked hard on them, wondering whether they have proven useful
17:57:10 [JeniT]
jar: if the CG is on board with the proposal, then they won't need it
17:57:51 [JeniT]
masinter: I'm happy you're making progress, and I like the parallel properties proposal
17:58:00 [JeniT]
... like that it's not tightly linked to HTTP
17:58:06 [JeniT]
... that servers don't have to exist
17:58:16 [JeniT]
noah: is there anything we should read?
17:59:37 [JeniT]
jar, jenit: don't think so right now
17:59:51 [masinter]
if you want to say "the copyright of A is C", and A is a JPEG impage of mickey mouse, you can talk about the JPEG encoding, the particular image, the drawing the image was scanned from, or the very idea of mickey.
18:00:49 [jar]
… and if you want to talk about all four at the same time?… e.g. how they relate to one another?...
18:01:37 [jar]
scribenicK: jar
18:01:59 [jar]
topic: Fragment Identifiers and Mime Types
18:02:09 [jar]
noah: Objective is to get to FPWG
18:02:17 [jar]
s/FPWG/FPWD/
18:03:11 [jar]
jt: Context: We're trying to tackle: fragment ids are defined in different specs, e.g. media fragments and the +xml media type(s) registration
18:03:26 [jar]
… How to resolve conflicts between these
18:03:27 [Zakim]
Zakim has joined #tagmem
18:04:11 [jar]
… We've been talking to Chris re 3023bis (+xml), with RDFa WG, and IETF media type reg process RFC draft
18:04:21 [masinter]
tools.ietf.org/html/draft-ietf-appsawg-media-type-regs
18:04:26 [masinter]
http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs
18:05:03 [jar]
… The present document is best practices for 4 groups of people: (see TOC)
18:06:17 [jar]
… those writing media type regs; those writing +xxx regs; those writing generic fragid semantics specs; people preparing documents [& sw that prepares]
18:07:08 [jar]
noah: Has anyone read this particular version?
18:08:01 [jar]
jt: I'll try to talk through the main points that the BP draft makes
18:08:23 [jar]
jt: 1. People writing media type regs. http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-05-28.html#registrations
18:09:10 [jar]
jt: You're subject to constraints. These come from several places. Other media types, scripting, etc. What to do?
18:09:34 [jar]
Coined term 'fragment identifier structures'
18:09:41 [jar]
s/Coined/jt: Coined/
18:11:52 [jar]
jt: If there are two kinds of generic processor that might apply to the documents, then the media type reg should reconcile … if there's a conflict, make a choice
18:12:11 [jar]
lm: The dependent clause is not determinable - whether there's a conflict is unknowable. Remove 2nd sentence?
18:13:07 [jar]
jt: You would drop the structure syntax by removing the +xxx in the media type name
18:13:43 [jar]
lm: If they're in conflict, you're better off not using the structure syntax (this isn't exactly a BP)
18:14:23 [jar]
noah: The doc uses both uppercase and lowercase 'should'… no mention of 2119
18:14:50 [jar]
… the mix was murky to me… SHOULD is normative
18:15:17 [jar]
lm: How about just explaining that uppercase (2119) is used in the BP notes (i.e. not outside them)
18:15:50 [jar]
noah: 'Best practice' has strong connotations.. maybe say 'good practice' instead?
18:16:57 [jar]
lm: The status of the IETF document could note that this document is in progress. If there's a durable URI we should be able to get them to mention in it
18:17:26 [jar]
noah: Important that the BPs are linkable.
18:18:27 [jar]
… (individually)
18:19:28 [masinter]
The document that I'd like to reference this is called a "BCP" "Best Current Practice"
18:21:53 [jar]
jt: BP #2. Conflicts betwen app-specific fragid structures that apply to the media type: explain how to resolve
18:22:14 [masinter]
does "special internal syntax" mean "punctuation" ? What about CamelCase identifiers? Or are some puncutation marks OK? What about names with spaces which are then %20 escaped?
18:22:36 [jar]
noah: There should be no syntactic overlap?
18:23:24 [masinter]
q+ to offer that everything we're talking about are quibbles and we could FPWD this version without any changes
18:23:57 [jar]
jt: There are fragids that are brought about generically, because of the 'supertype' of the media type. Then there are fragids that come about because of specific applications. BP #2 is between instances of the latter
18:24:46 [masinter]
put parentheses around "as in the music notation example above" between BP1 and BP2
18:24:54 [jar]
noah: If you're a +xml and there's an xpointer, it's xpointer, full stop.
18:26:00 [jar]
timbl: What about rdf+xml?
18:26:06 [jar]
jt: Hang on, that comes later
18:26:16 [jar]
q?
18:27:41 [jar]
noah: I read this differently
18:28:39 [jar]
jt: Don't land-grab on barenames. Currently +xml specifies both xpointer and barenames; it would be better if only said xpointer
18:29:28 [jar]
noah: Problem regarding evolution of the xpointer spec- a future version might claim more syntactic space
18:31:16 [jar]
lm: I'd be happy with this as fpwd as is. For BP#3, what about new formats not based on XML, e.g. json-based. No barenames anywhere? Is that bad practice? What is justification for singling out barenames [?]? Maybe I have multiple kinds of things named by authors.
18:31:57 [jar]
jt: In XML schema you have types named by authors and elements named by authors
18:32:09 [jar]
noah: a bit hard to read.
18:32:35 [jar]
lm: Perhaps this is about worst practices, not best practices
18:33:41 [jar]
timbl: bare names are common to many languages, including future ones. original architecture was for local identifiers, defined using definition mechanism of any language
18:34:25 [jar]
jt: Authors want to put anchors in documents… places they can get at
18:35:25 [jar]
timbl: With a bit of effort we can make it much more interesting, e.g. javascript variable names. Don't use id in your language for anything other than global names
18:35:57 [jar]
lm: The names aren't generated by author always, sometimes by the authoring tool. Plain names are more like local ids and less about syntactic structures.
18:36:24 [jar]
… Can it have spaces? Can it use dots? dashes? those are syntactic structures
18:37:41 [masinter]
"should be used to address" => "should be reserved for addressing"
18:37:50 [jar]
timbl: It's been frustrating that N3 is C-like, no minus signs. Then RDF people use dashes because they work in XML. Don't serialize nicely in N3. Turtle gave in because of XML pressure. Personal practice: no punctuation in bare names, even if your favorite language likes them
18:38:47 [jar]
lm: In the context of media types, you're not talking about addressing, but reserving a style for the purpose of addressing
18:40:41 [jar]
jt: BP#4: Media type regs should talk about scripts. Maybe reserve part of namespace for use by scripts.
18:41:18 [masinter]
sentence 1 of para before BP#4 is a definition of "active content"
18:41:36 [timbl]
s/likes/allows/
18:42:02 [masinter]
and "scripts" is "user provided", where the scripts are part of what is downloaded
18:42:04 [jar]
noah: Add a new tag to XML? Oh that's a circle, I can fake that using a canvas tag. Scripts operate on document content too. The fragid isn't always just a parameter to the script
18:42:39 [jar]
… There are times when scripts are tempted to squat on parts of the address space that might be in use for something else
18:42:41 [masinter]
"the developers of scripts should ensure" seems misplaced
18:44:22 [timbl]
s/them/them (JSON for example doesn't have - or . in local names, and so names imported from XML will break if they have punctuation within them. So a good practice is to avoid punctuation characters characters in localids.)/
18:45:37 [jar]
noah: Misread that BP. First talk about how tags are interpreted when the scripts don't run… then say scripts shouldn't conflict with that
18:45:53 [masinter]
not sure "scripts" is the right word -- does this work for java applets?
18:45:57 [jar]
ashok: Should specify how scripts use fragment identifiers
18:46:18 [jar]
jt: Maybe this is two separate practices
18:46:21 [masinter]
"scripts" => "active content" everywhere?
18:47:21 [jar]
jt: #5: If you're going to define a fragid structure, do it in a separate document so people can reference it separately.
18:47:52 [jar]
ashok: Didn't we say the reg should define …?
18:47:56 [masinter]
for ...? for reusability? for consistency?
18:48:18 [masinter]
for modularity?
18:48:26 [jar]
jt: The reg should list the applicable structures, usually with references to independent specs
18:48:42 [jar]
ht: It's a 'should' only because sometimes the independent spec doesn't exist
18:49:04 [jar]
… if the spec exists maybe the reg MUST reference it?
18:49:52 [jar]
noah: Suppose I have a need for specialized fragids, are you saying I should provide it in a separate spec?
18:50:32 [jar]
… Consider factoring the spec, or looking to see if there's already a factored spec
18:50:49 [jar]
noah: The sentence has multiple parses
18:51:11 [jar]
… if they exist, vs. creating them as necessary
18:51:25 [jar]
lm: If the justifications are modularity and reuse, the previous paragraph should say so
18:52:24 [jar]
jt: #6: Should say what happens if a fragid is undefined - either it's outside syntactic space, or it's not defined semantically
18:53:54 [jar]
noah: Unresolved fragids comes up in parts of the architecture… where are you going with that?
18:54:04 [masinter]
noah: if you're describing what fragment identifiers identify, then if things don't match, you don't say. Where is this going?
18:54:52 [jar]
timbl: This is a funny area. There are lots of media types out there, … (missed)
18:55:31 [jar]
jt: E.g. say that if there's no fragid defined in the HTML, then you should go to the top of the document…
18:56:38 [jar]
timbl: Bad idea for the spec to say what the user application is supposed to do. Maybe browser is a special case, but in data processing in general, it all depends, and the spec shouldn't try to nail behavior down
18:57:10 [jar]
timbl: Operational commitments, like what we find in XML and HTML, are not a good idea
18:58:37 [jar]
noah: Identifiers resolve, or they don't. Or you could say that since all ids seem to appear something in the document (usually)… (missed)
18:58:52 [jar]
noah: Better to say less. E.g. just say that some ids don't resolve.
19:00:26 [jar]
noah: The behavior when the pre-# part resolves but the fragid doesn't is best specified by the consuming application
19:01:03 [jar]
… disagree that #6 is a best practice
19:01:31 [jar]
jt: What if it's invalid syntactically?
19:01:47 [jar]
noah: I wouldn't expect much commonality between consumers
19:02:39 [jar]
jt: Section 3, re things like +xml and +json
19:05:08 [jar]
jt: It was trying avoid the +xml case where it said that all fragments had to be interpreted as xpointer, leaving no room for the specific media type registration.
19:06:34 [jar]
timbl: Needs to be crisper. If you're talking about media types adopting a variety of structures. Was this deliberate? Or it ended up being covered by a suffix? You could make a structure that simultaneously matches two specs, or do you decide which syntax it is and choose which structure applies?
19:08:29 [jar]
… you must not use any other registration that overlaps with my syntax because it has the bugs you say. but if it's not overlapping, supporting both shouldn't be precluded
19:09:30 [jar]
timbl: You're trying to say, use up a small part of the syntactic space
19:10:27 [jar]
jt: #7 is saying that if it's not covered in +, then it devolves to the specific media type
19:11:42 [jar]
jt: #8 says that + registrations shouldn't cover bare names
19:11:58 [jar]
ht: If Chris does what we asked them before, it will contradict this advice
19:12:12 [jar]
jt: We discussed this in Antibes
19:12:54 [jar]
ht: #8 and #9 conflict for XML. The xpointer framework includes barenames
19:13:06 [jar]
jt: +xml doesn't need to adopt it in its entirety
19:13:54 [jar]
ht: if 3023bis doesn't say that it adopts xpointer, we have trouble
19:14:35 [jar]
lm: The conclusion is that the +xml definition is not best practice.
19:16:12 [jar]
(going meta)
19:20:02 [masinter`]
masinter` has joined #tagmem
19:20:30 [jar]
ht: (Reading resolution passed in Antibes re 3023bis)
19:20:53 [jar]
ht: It's on a case by case basis, not a syntactic category basis
19:21:23 [jar]
ht: This was at the end of a long discussion, and everyone agreed
19:21:48 [ht]
I read from these minutes: http://www.w3.org/2001/tag/2012/04/04-minutes#item02
19:22:04 [masinter`]
the appsawg documents are not on http://datatracker.ietf.org/iesg/agenda/documents/
19:22:36 [ht]
The relevant bit is in red many pages down from that link, in practice easier to reach a few pages _up_ from http://www.w3.org/2001/tag/2012/04/04-minutes#item03
19:22:37 [jar]
noah: Right. There's precedent for saying that some identifiers resolve and others don't, and the ones that don't get their semantics elsewhere
19:23:02 [jar]
jt: "… but if they do, they should at least leave the ones that don't resolve to …"
19:23:14 [jar]
noah: They apply to any potentially overlapping syntax
19:23:51 [jar]
ht: We didn't leave it to bare names, it was for any overlapping syntax
19:24:29 [jar]
noah: Action at a distance risk
19:24:33 [jar]
ht: That's why it's a should
19:25:17 [jar]
noah: Explain the tradeoff. This advice was given for xml because...
19:25:39 [jar]
ht: This doc goes back on what we worked hard on in Antibes… problem
19:26:12 [masinter`]
my reading of IESG tracker http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ is that today vs thursday doesn't matter.
19:26:56 [jar]
ht: Last draft published 6 days ago.
19:27:31 [jar]
lm: Draft is not on their agenda for the next couple of weeks. But I can give editors a heads-up
19:29:40 [jar]
scheduling
19:33:01 [jar]
Adjourned until tomorrow.
19:33:10 [jar]
rrsagent, pointer
19:33:10 [RRSAgent]
See http://www.w3.org/2012/06/12-tagmem-irc#T19-33-10
20:31:46 [ht]
ht has joined #tagmem
20:36:06 [Zakim]
Zakim has left #tagmem
21:15:45 [Norm]
Norm has joined #tagmem
21:16:57 [Norm]
Norm has joined #tagmem
22:45:14 [Norm]
Norm has joined #tagmem