Technical Architecture Group F2F Day 1

NM: Minutes of 24/5?

NM: RESOLUTION: Minutes of 24/5 at http://www.w3.org/2001/tag/2012/05/24-minutes approved

Privacy by Design in APIs for Web Applications

<noah> Work plan not approved: http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html

NM: I believe we do not yet have an approved workplan for this

RB: Correct
... Not sure that's the latest draft

<darobin> http://www.w3.org/2001/tag/products/apiminimization.html

<masinter> that one isn't dated

<masinter> oh it is at bottom kind of

RB: I'll walk us through the changes
... since Nice f2f

<darobin> http://darobin.github.com/api-design-privacy/api-design-privacy.html

<plinss> http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis-2012-06-06.html

<masinter> http://tools.ietf.org/id/draft-hansen-privacy-terminology-00.html has been updated

RB: Feedback at f2f and from others have led to changes

<masinter> http://tools.ietf.org/id/draft-iab-privacy-terminology-01.html is latest draft

RB: It is trying to address two communities which is tricky
... The privacy c'ty and the API creators
... A lot of the feedback was on providing more background
... So I've reworked the intro wrt scope, also added a section on that specifically
... To be clear about the small part of the privacy space we are targetting
... This is in contrast to a lot of other privacy work which IMO has too large a scope
... So just APIs, and just privacy perspective on APIs

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
... Aren't you going to get the response "I'll write my app the way I want to"?

RB: Not sure I understand the distinction

<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?)

<masinter> perhaps there are other design patterns, like origin, which creates sandboxes

RB: In the other document . . .

AM: No, in this one, at the end

RB: This doc. is only aimed at API designers, not app authors.

NM: Maybe the same point? When you mentioned Saltser & Schroeder, I thought I understood -- they say the API strictly limits what non-privileged apps can do, but tells you how you can do a lot none-the-less.
... But in their case they assume that those limits are enforced.

<masinter> DNT is a policy-transmission API

<masinter> I'm taking the view that 'API' and 'network protocol' isn't that different

NM: 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

RB: Granularity is only one part of the overall approach
... That's in the minimization section
... In the other parts, there is dicussion about privilege separation
... So e.g. in the vibration API, it fails w/o saying that's because there is no sensor, so not exposing that information

<noah> My concern is mainly about the minimization part, and the Schroeder reference in that context

RB: Granularity allows easy exposure to the user of what's being accessed/required/used

<masinter> http://tools.ietf.org/html/draft-iab-privacy-considerations-02 should be background, why is this document so different a context?

<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

<masinter> Design APIs so that it's hard to write buggy apps

RB: 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

<Zakim> jar, you wanted to unpack "malicious"

JAR: I have said this before and heard no pushback -- there's a difference between security and privacy
... The purpose of minimization is not to provide a security mechanism
... But to reduce temptation
... 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
... Removing possible sources of temptation

<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.

TBL: Temptation or attack?

<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.

<masinter> http://tools.ietf.org/html/draft-iab-privacy-considerations-02#page-5

JAR: If you ask if you can borrow a book, and I lay the book on the table and put a $20 next to it, is it an attack if you take the $20?
... policy, "nothing there to protect" [scribe missed]

<noah> Now I sort of get it a bit, but I think minimization affects privacy too, e.g. to minimize risk of unintentional loss.

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

AM: Section 4.1, example, "discover lots of stuff about each mouse" -- what are we going to do about this

<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"

AM: Where in the API can anything prevent/signal/call attention to this?

RB: This is an anti-pattern -- don't do this -- it's appeared in lots of apps in various ways
... Recent e.g. mouse APIs have been designed so that this isn't possible anymore
... 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

AM: So the API won't support getAllMice()?

RB: That information won't be available if the API is designed right

<masinter> I have three points: background & terminology; protocol and APIs equivalence; missing design patterns

<noah> Larry says there's a new version of http://tools.ietf.org/id/draft-hansen-privacy-terminology-00.html

LM: I do see a reference to Hannes [Tschofenig]'s document -- there's a newer version, which is now an IAB [???] [scribe missed]

RB: I spoke with Christine [Runnegar], and then with Hannes [Tschofenig] 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

LM: There's also a draft about privacy considerations more generally: http://tools.ietf.org/html/draft-iab-privacy-considerations-02#page-5

<timbl> (Fascnating: http://tools.ietf.org/html/draft-iab-privacy-considerations-99 redirects to http://tools.ietf.org/html/draft-iab-privacy-considerations-02 !)

LM: I think there's a near-equivalence between privacy wrt protocols and privacy wrt APIs, so minimization, which is discussed in that draft
... Also, I note that this doc talks about threats and attacks, both wrt privacy and wrt security

<masinter> the terminology uses "threat" and "attack" but in different context

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.

LM: Given that framework, there are various design patterns -- GeoPriv e.g. increases the API to include policy information, particulary regarding redistribution
... Similarly the Do Not Track header is a policy statement

<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)

<jar> I think there's a Venn diagram, with bins (1) privacy not security, (2) privacy and security, (3) security not privacy

LM: [earlier] The protocol/API parallel reminds us that what you do with what you get is part of the equation

<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

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
... but people argued about that, and said we needed references, so we took it out

LM: I at least pushed back on the use of a common vocabulary, not that they were completely separate

NM: I heard you try to avoid making that distinction and focus on the doc.

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

LM: My argument is about vocabulary, not about scope
... I don't mind limiting the scope, but I do care that we don't invent new vocabulary
... We should use "threat", which is what the IAB use

RB: I just don't want to do that until they stabilize
... They've already said changes are coming

LM: OK

NM: JAR, does that address your problem?

<masinter> sandboxing

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

<darobin> http://www.w3.org/2012/05/sysapps-wg-charter.html

JAR: And the other think that's odd is the absence of discussion about secure Javascript

<masinter> policy and sandboxing are missing

RB: Yes, of course if you have a security hole privacy attacks may be enabled, but that doesn't affect API design
... That is, I won't expect any change to an API if you were worried about security holes

JAR: Not clear to me that's true

<masinter> Robin, could you say who on IAB told you that we shouldn't reference the IAB documents for terminology and privacy considerations?

<masinter> I'd like to follow up

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

NM: Change scope, or title?

JAR: Title, I think, plus some references to what else they need to know
... I need to review the Scope section

<masinter> Is PING coming up with their own terminology document?

NM: Would you, RB, be able to add some pointers?

RB: Not sure I understand what's wanted well enough, no
... But if JAR can help, I'm happy to work to improve things in that area

YL: The focus on unwanted data access is both privacy and security, w/o claiming that that's all of either topic
... But the fingerprinting part isn't part of API design I don't think
... So I'd like the document to focus only on the part about not exposing unwanted-to-be-exposed data

<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"

<masinter> the "privacy considerations" document is more than terminology, and also applicable.

<masinter> if this is a topic for PING, should the TAG wait until IAB and PING converge?

AM: We thrashed on privacy for a while and only agreed to tackle this at all when DA proposed this very narrow topic

AM: So I'm worried that JAR's concerns are widening things again

<masinter> and what about other design patterns not covered?

<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

AM: I liked the old "Data Minimization" title

<darobin> actually the previous version of the product page that broadened the scope was approved IIRC

NM: But when RB took on the document, he did so on the basis of expanding the scope a bit
... and that title reflects that

<masinter> http://tools.ietf.org/html/draft-iab-privacy-considerations-02#section-4.1 is "Data Minimization"

<darobin> Yves, yes, you can't use just section 4.4 — you mostly need sections 4.1-4.3 ;)

<Yves> darobin: not only

<darobin> Yves, what else do you need when designing new APIs (I'm not talking about handling the existing mess)

<Yves> I mean that you might fingerprint by merely using multiple apis

<Yves> so you need specific policies to avoid mixing that information to generate accurate identifiers

AB: I would recommend going back to the original scope, because then we can publish more quickly

<masinter> Data minimization is comprised of a number of mutually exclusive sub-goals:

LM: [summarizes IAB doc't on DM]
... I think we should collaborate with this

LM: If they're not ready to collaborate, we should wait until they are

AM: But we, and they, having been working for a long time

LM: They are talking about protocols, we are talking about APIs, so there's a difference

<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...

<darobin> jar, how does policy transmission affect API design?

<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

<darobin> Yves, if individual APIs do not yield identifying information, having more of them won't help identify more I would think

<darobin> jar, that's known as the GeoPriv anti-pattern :)

<Yves> darobin, it depends on the level of fuzziness ;)

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
... But then of course things such as Kindle Fire muddy the waters

<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

<darobin> jar, well, the primary argument against it is that politically it won't happen

<darobin> but it's true that I could include a section on antipatterns

<jar> but it is happening - as DNT

<darobin> which is 100% orthogonal to API design — not the pattern you describe

<jar> disagree. it's policy transmission.

<Yves> antipatterns would be a good idea indeed

NM: Should we add something to the draft about this connection, at least to signal it exists and aim for cooperation

LM: Yes

RB: That sounds good to me, yes

<darobin> jar, it changes nothing to how you design the API

<jar> any API that's involved in implementing DNT policy will have to have a way to transmit the DNT policy

<darobin> jar, JS APIs won't even touch DNT

<Zakim> darobin, you wanted to say my identity is also information I don't want to give access to

NM: 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"

<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" [recorded in http://www.w3.org/2001/tag/2012/06/12-minutes.html#action01]

<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].

<jar> isn't DNT binding on ajax?

<darobin> Ajax isn't a JS API

<darobin> it's network

<jar> XHR

<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

<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"

AM: This will never finish if we do this

NM: We're only talking about trying to be consistent, not trying to have a jointly agreed outcome

LM: Who is Christine?

<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.

<Ashok> Christine Runnegar

RB: I've been emailing with Hannes Tschofenig and Alissa Cooper, and Christine Runnegar who is co-chair of the Privacy Interest Group
... That's the W3C Privacy IG, and Alissa is on that group, so that seems like a good place to have this discussion

NM: So I'd like to turn to the process by which we get this published as a PWD

LM: Shouldn't this be being produced by the Privacy IG?

AM: They're an IG, and they have 1 call per month

RB: It's early days for them, they aren't ready to take this one

HST: If they ever fork a WG, maybe we park our WD based on calling it input into their work

LM: Could NM at least officially ask them if it is ok that we are doing this

NM: Sure, if we agree to go ahead

<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

<masinter> i don't think the TAG should take this on if there's a working group chartered to do this

.ACTION: NM to email Christine Runnegar that we are about to publish this doc't and offering to coordinate with them on who does what

LM: I don't think we should be doing this
... I think a group dedicated to working on privacy should do this
... I'm willing for the TAG to work on it until there is such a group
... but only until then

<masinter> this is a small part of "how to design for privacy"

<darobin> [if the TAG were to drop this document, it would likely get published in DAP in cooperation with PING]

LM: The W3C needs to do the whole thing, not just this

<jar> prefixing the title with the word "some" might address my concern

LM: The whole thing is very big

<masinter> the tag can't do the whole thing

<masinter> i think this is something we can start on

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

<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.

<darobin> jar, I am not aware of a single "patterns" document that claims to cover all patterns?

JAR: If we changed the title to "Some Patterns for Privacy. . .", that would help me -- LM?

LM: Yes, along with a preface about where this fits, as a Note

<darobin> +1 to Jeni!

JT: More important to publish now than discuss where it fits indefinitely

<Ashok> +1

<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'

NM: LM you surprised me

LM: The TAG should lead, which means getting others to follow

<masinter> i don't think what we have is a complete set of design patterns for privacy

NM: Is this publish and quit, or are we aiming for a good job, which we will edit in response to feedback

LM: What we have doesn't cover all the things in might, including sandboxing, secure Javascript and policy transmission
... so we don't claim it's exhaustive

NM: OK, so do we publish it to get feedback and promise to revise, etc.
... or do we expect to just hand it off and stop there?
... 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.

<darobin> FWIW, I think that there are only two options forward: FPWD and keep going, or pass it to another group

<masinter> i have a low barrier for FPWD as long as the disclaimer

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?

LM: Yes, but conditional on a) IAB ref; b) not all of privacy; c) belongs elsewhere.

<masinter> to be useful, this has to be only one of a suite of documents about privacy

<JeniT> masinter, that's true, but we don't get to do a suite of documents without starting somewhere

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

HST: I don't agree with LM's caveat (c) -- we are committing to do this

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.

LM: A world in which this is the only W3C doc't on Privacy in apps would not be a good one.

<darobin> [especially since this document is not at all about building privacy aware applications at all]

NM: Agreed, but not by putting that language in this document.

LM: So where do we say we think there should be "a WG producing RECs on privacy"?

NM: We can talk about how to take this forward elsewhere, can we just publish the document?

PL: Can we put this on the product page

<timbl> Proposal: ACTION noah contact JJ to pass on the message that the TAG thnks that W3C should have a working group working on Privacy

<jar> this is an argument over what gets written in the 'status' section, right?

NM: So the product page will only track the narrow document, I will take an action to communicate the larger need

<noah> . RESOLUTION: the TAG thinks that W3C should have a working group working on Privacy

<masinter> which should take on as one of its work product to take on this document

<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)

<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

. 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

<masinter> +1

<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

<noah> Passes without dissent

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

<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].

NM: Objections to moving forward with the document?

[none]

NM: Objections to FPWD on the Rec track?

[none]

<masinter> FPWD, doesn't need to say "rec trac"

<masinter> +1 to adding word 'some' to title

NM: Add the word "Some"?

[no objections]

<noah> Accepted without objection: add "some" to the title

<darobin> http://www.w3.org/2001/tag/products/apiminimization.html

<JeniT> http://www.w3.org/2001/tag/products/apiminimization-2012-06-08.html

<noah> http://www.w3.org/2001/tag/products/apiminimization-2012-06-08.html

<darobin> I still wonder if anyone has ever seen a patterns document claiming to exhaustively document all patterns but shrug, won't bikeshed :)

<JeniT> why ever not?

<darobin> JeniT, they're all about "some patterns" :)

<darobin> jenit, but hey, I think a slightly brighter shade of pink might catch the light better

HST: Propose replacing "TBD: an approved TAG finding on API Privacy by Design" with disjunction:

HST: Either:

HST: * We publish a document (could be finding, rec, note TBD) -or-

HST: * This gets handed over to new privacy group

<darobin> should the product page make the assumption that a new privacy group will be chartered?

<masinter> question for product page to include liaison with IAB and PING

<Yves> might be chartered

HST: Prefer not to get into details of handing over and to whom in the product page

LM: Adding something about liaison helps clarify our goals
... We will be committed to trying to resolve any disagreements

<noah> close ACTION-684

<trackbot> ACTION-684 Update Privacy by Design in APIs closed

<darobin> here's the same document as a FPWD :) http://darobin.github.com/api-design-privacy/api-design-privacy.html?specStatus=FPWD

<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 [recorded in http://www.w3.org/2001/tag/2012/06/12-minutes.html#action02]

<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].

NM: Need an action on the Product Page

<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

<darobin> I really have to leave — sorry

<darobin> please just give me actions!

NM: Is a goal that we initiate further W3C work?

LM: Yes

NM: Objections?

<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

[none]

<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 [recorded in http://www.w3.org/2001/tag/2012/06/12-minutes.html#action03]

<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].

<noah> ACTION-650?

<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

<trackbot> http://www.w3.org/2001/tag/group/track/actions/650

<noah> JAR: no need for attention now.

ACTION-563: Periodic TAG key issues reports to Jeff Jaffe

NM: We will owe an issue update in the autumn to JJ

LM: Things we the TAG have struggled with:
... XML and HTML are on divergent tracks, and they are both important to the W3C

<masinter> Distributed Extensibility

<masinter> apps vs. web

<masinter> for mobile

JAR: How do we frame this for JJ? Our previous message got the response: OK, so what do we do about it?

NM: We should remember to revisit our last list before we do a new one. . .

AM: What if we work back from "What does the W3C want to accomplish?"

<masinter> boundary between 'web' and 'non-web' for apps?

AM: For example, getting more uptake for the Semantic Web

<jar> semantic web is a means to an end... what's the end?

NM: JJ asked for alerts about things happening "out there" that he should be aware of
... Net neutrality? Installing servers "near the edges"

TBL: Pushing it, or defining it?

NM: Things which undermine the equality of access on the Web happen all the time

TBL: That's a given

<Zakim> ht, you wanted to mention aging/companions/communities

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
... Using Web technology, in particular social Web technology, to address problems especially of older people learning alone.
... Story about study in UK that death rates could be cut dramatically if those at risk check their feet everyday.
... Relates to gangreen and diabetes. Old people can't easily see their feet.
... I'm thinking of communities that are housebound

<masinter> distance ed

<masinter> video

TBL: Judy has some funding in this area. It's not a new idea, but it is important.

<masinter> gamification

<masinter> globalization

<masinter> i18n isn't good enough

<Zakim> JeniT, you wanted to raise distributed web applications (eg unhosted)

<masinter> game-ificaiton

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

AM: Linked Data Platform (LDP) is not about unhosted data
... There target is extending REST to Linked Data

<JeniT> http://unhosted.org/

<jar> unhosted is analogous to patient-controlled EHRs

<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."

TBL: Aren't they talking about separating app from data?
... decoupling provision of stores from provision of apps

NM: Is unhosted like AJAX, a way of thinking about your app?

JT: Yes, but also a concrete implementation, which you can import to give access to multiple sources of (encrypted) data

NM: So it is AJAX like, with some concrete JS support

JT: Different from mashups is that e.g. Craigs List and google supplied the data for them,
... whereas unhosted means you supply the data

AM: So when you start an app, do you spell out which sources of data to access?

JT: I think so, but not sure

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?"

<masinter> spaces?

<masinter> facebook, identity, "social"

TBL: So that we can choose stores for different data parts based on the properties, e.g. privacy, they provide

<Zakim> jar, you wanted to webp2p , http://cyber.law.harvard.edu/node/5136

<jar> http://www.mendeley.com/research/indivo-x-developing-fully-substitutable-personally-controlled-health-record-platform/

JAR: I keep coming back to peer-to-peer -- has it heated up enough?

JAR: There's a web-p-to-p mailing list, which has been sort of quiet lately

<jar> comment on my scribed comment above re webp2p: the list isn't quiet; rather it's nascent, mostly introductions now, some interesting discussion

JAR: My fantasy is of p-to-p as a backup for the Web when the servers stop working

<jar> or DNS

<jar> http://tesla.lcs.mit.edu/publications/Papers/sheldon.pdf

<masinter> does webrtc/rtcweb change skype / connect / webex ?

<masinter> "web of video" "hypervideo" ?

<masinter> just brainstorming

<masinter> impact / likelihood of action / timeliness

<masinter> vertical application spaces with near-term web impact

<Zakim> ht, you wanted to raise the remote join question

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

HT: general sense...probably not now

ht: Is there anything important happening in this space, that it should get attention?

<JeniT> http://www.w3.org/TR/sparql11-federated-query/

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

TBL: and then uses those source to do the remote joing
... The second part has been well studied, but the first has not

<Zakim> masinter, you wanted to give some new topics, disruption of higher ed

<masinter> http://www.khanacademy.org/

<masinter> note "ni:" scheme discussion

<masinter> http://tools.ietf.org/html/draft-farrell-decade-ni

LM: Verticals with possible disruptive near-term impact: healthcare and higher education
... Some threshhold wrt higher education on the web seems to be being crossed
... Maybe healthcare
... RTC Web -- peer-to-peer video is another potential problem area

HST: IETF work isn't adequate?

LM: I think some things are maybe falling in the gaps. . .
... IETF is doing protocols, W3C the APIS, but I'm not sure it's all covered

<jar> another p2p thing to be aware of might be the ietf decade wg... possible evidence of foment?

<masinter> move of more things from text => video mean hypervideo

HT: What about identity (of people)

JAR: W3C hired someone, Wendy Seltzer

<jar> one question is whether there is coordination between browserid & webid... but i'd be surprised if there weren't

NM: Adjourned until 1345

Thread on acct: URI scheme: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05957.html

Quick report from lunchtime ISSUE-57 breakout group

jar: plan for Thursday's session on ISSUE-57
... two problems: technical and procedural
... jar, ht, JeniT & timbl have been exchanging emails behind the scenes
... we have a rough consensus
... technical part is to present "parallel properties" idea
... has been around for 10 years, in some form or another
... we have thoughts in terms of how to present or sell it, to see it differently
... procedurally, first is to report back to the community about change proposals
... then to prepare a document presenting "parallel properties" idea
... then spin up a community group

Ashok: if we spin up a CG, is the TAG off the hook

jar: that's part of the question, it depends on the purpose of the CG
... if the purpose is to solve the problem, it would require the TAG to have some level of commitment to the group
... required for continuity for what we've been doing over last couple of months
... take the draft as a starting point
... the matrix would be an input to the CG

noah: what about the other documents you produced? are they still useful points of reference?

jar: if someone has questions about why particular options were discarded, then yes, but more for that historical purpose
... easiest thing is to give CG a bibliography, harder to provide an orientation document
... let the group start meeting, and see if they need it

noah: we worked hard on them, wondering whether they have proven useful

jar: if the CG is on board with the proposal, then they won't need it

masinter: I'm happy you're making progress, and I like the parallel properties proposal
... like that it's not tightly linked to HTTP
... that servers don't have to exist

noah: is there anything we should read?

jar, jenit: don't think so right now

<masinter> if you want to say "the copyright of A is C", and A is a JPEG image 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.

<jar> ... and if you want to talk about all four at the same time?... e.g. how they relate to one another?...

Fragment Identifiers and Mime Types

noah: Objective is to get to FPWD

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
... How to resolve conflicts between these
... We've been talking to Chris re 3023bis (+xml), with RDFa WG, and IETF media type reg process RFC draft

<masinter> http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs

jt: The present document is best practices for 4 groups of people: (see TOC)
... those writing media type regs; those writing +xxx regs; those writing generic fragid semantics specs; people preparing documents [& sw that prepares]

noah: Has anyone read this particular version?

jt: I'll try to talk through the main points that the BP draft makes
... 1. People writing media type regs. http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-05-28.html#registrations
... You're subject to constraints. These come from several places. Other media types, scripting, etc. What to do?
... Coined term 'fragment identifier structures'
... 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

lm: The dependent clause is not determinable - whether there's a conflict is unknowable. Remove 2nd sentence?

jt: You would drop the structure syntax by removing the +xxx in the media type name

lm: If they're in conflict, you're better off not using the structure syntax (this isn't exactly a BP)

noah: The doc uses both uppercase and lowercase 'should'... no mention of 2119
... the mix was murky to me... SHOULD is normative

lm: How about just explaining that uppercase (2119) is used in the BP notes (i.e. not outside them)

noah: 'Best practice' has strong connotations.. maybe say 'good practice' instead?

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

noah: Important that the BPs are linkable.
... (individually)

<masinter> The document that I'd like to reference this is called a "BCP" "Best Current Practice"

jt: BP #2. Conflicts betwen app-specific fragid structures that apply to the media type: explain how to resolve

<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?

noah: There should be no syntactic overlap?

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

<masinter> put parentheses around "as in the music notation example above" between BP1 and BP2

noah: If you're a +xml and there's an xpointer, it's xpointer, full stop.

timbl: What about rdf+xml?

jt: Hang on, that comes later

noah: I read this differently

jt: Don't land-grab on barenames. Currently +xml specifies both xpointer and barenames; it would be better if only said xpointer

noah: Problem regarding evolution of the xpointer spec- a future version might claim more syntactic space

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.

jt: In XML schema you have types named by authors and elements named by authors

noah: a bit hard to read.

lm: Perhaps this is about worst practices, not best practices

timbl: bare names are common to many languages, including future ones. original architecture was for local identifiers, defined using definition mechanism of any language

jt: Authors want to put anchors in documents... places they can get at

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

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.
... Can it have spaces? Can it use dots? dashes? those are syntactic structures

<masinter> "should be used to address" => "should be reserved for addressing"

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 allows 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.)

lm: In the context of media types, you're not talking about addressing, but reserving a style for the purpose of addressing

jt: BP#4: Media type regs should talk about scripts. Maybe reserve part of namespace for use by scripts.

<masinter> sentence 1 of para before BP#4 is a definition of "active content"

<masinter> and "scripts" is "user provided", where the scripts are part of what is downloaded

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
... There are times when scripts are tempted to squat on parts of the address space that might be in use for something else

<masinter> "the developers of scripts should ensure" seems misplaced

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

<masinter> not sure "scripts" is the right word -- does this work for java applets?

ashok: Should specify how scripts use fragment identifiers

jt: Maybe this is two separate practices

<masinter> "scripts" => "active content" everywhere?

jt: #5: If you're going to define a fragid structure, do it in a separate document so people can reference it separately.

ashok: Didn't we say the reg should define ...?

<masinter> for ...? for reusability? for consistency?

<masinter> for modularity?

jt: The reg should list the applicable structures, usually with references to independent specs

ht: It's a 'should' only because sometimes the independent spec doesn't exist
... if the spec exists maybe the reg MUST reference it?

noah: Suppose I have a need for specialized fragids, are you saying I should provide it in a separate spec?
... Consider factoring the spec, or looking to see if there's already a factored spec
... The sentence has multiple parses
... if they exist, vs. creating them as necessary

lm: If the justifications are modularity and reuse, the previous paragraph should say so

jt: #6: Should say what happens if a fragid is undefined - either it's outside syntactic space, or it's not defined semantically

noah: Unresolved fragids comes up in parts of the architecture... where are you going with that?

<masinter> noah: if you're describing what fragment identifiers identify, then if things don't match, you don't say. Where is this going?

timbl: This is a funny area. There are lots of media types out there, [???] [scribe missed]

jt: E.g. say that if there's no fragid defined in the HTML, then you should go to the top of the document...

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
... Operational commitments, like what we find in XML and HTML, are not a good idea

noah: Identifiers resolve, or they don't. Or you could say that since all ids seem to appear something in the document (usually) [???] [scribe missed]
... Better to say less. E.g. just say that some ids don't resolve.
... The behavior when the pre-# part resolves but the fragid doesn't is best specified by the consuming application
... disagree that #6 is a best practice

jt: What if it's invalid syntactically?

noah: I wouldn't expect much commonality between consumers

jt: Section 3, re things like +xml and +json
... 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.

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?
... 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
... You're trying to say, use up a small part of the syntactic space

jt: #7 is saying that if it's not covered in +, then it devolves to the specific media type
... #8 says that + registrations shouldn't cover bare names

ht: If Chris does what we asked them before, it will contradict this advice

jt: We discussed this in Antibes

ht: #8 and #9 conflict for XML. The xpointer framework includes barenames

jt: +xml doesn't need to adopt it in its entirety

ht: if 3023bis doesn't say that it adopts xpointer, we have trouble

lm: The conclusion is that the +xml definition is not best practice.

(going meta)

ht: (Reading resolution passed in Antibes re 3023bis)
... It's on a case by case basis, not a syntactic category basis
... This was at the end of a long discussion, and everyone agreed

<ht> I read from these minutes: http://www.w3.org/2001/tag/2012/04/04-minutes#item02

<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

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

jt: "... but if they do, they should at least leave the ones that don't resolve to ..."

noah: They apply to any potentially overlapping syntax

ht: We didn't leave it to bare names, it was for any overlapping syntax

noah: Action at a distance risk

ht: That's why it's a should

noah: Explain the tradeoff. This advice was given for xml because...

ht: This doc goes back on what we worked hard on in Antibes... problem
... Last draft published 6 days ago.

lm: Draft is not on their agenda for the next couple of weeks. But I can give editors a heads-up

scheduling

Adjourned until tomorrow.