See also: IRC log
NM: Minutes of 24/5?
NM: RESOLUTION: Minutes of 24/5 at http://www.w3.org/2001/tag/2012/05/24-minutes approved
<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
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
<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.
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: 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
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?...
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.