See also: IRC log
<trackbot> Date: 20 October 2010
<johnk> Scribe: John Kemp
<johnk> ScribeNick: johnk
<jar_> http://www.w3.org/2001/tag/2010/10/persistent-reference-slides.pdf
NM: Quick agenda recap
... first topic is domain name persistence
... followed by Web App Architecture overview and privacy
... We have outside visitors in the afternoon
... *now* Domain Name Persistence
JAR: Reviewing these slides - http://www.w3.org/2001/tag/2010/10/persistent-reference-slides.pdf
<raman> .
JAR: summarizing my memo from last week - http://www.w3.org/2001/tag/doc/persistent-reference/
... document persistence vs. reference persistence
... persistence is a "gamble" - no engineering solution that can guarantee persistence
... so persistence says "there is a good bet this thing will be around in 100 years"
... so there is a threat model talking about threats to that bet
... TAG choices:
... i) embrace pluralism of solutions
... ii) advocate for HTTP only - be convincing
... iii) say nothing (~status quo)
... scholarly publishing state of art contains DOIs in "hybrid refs" - textual metadata + a persistent, clickable DOI
... clickable DOI is actually an HTTP URI
<timbl_> Zakim?
JAR: if you say "just use HTTP", all the DOIs become HTTP URIs
... W3C uses this "just use HTTP" model
... "Just say HTTP" - make a statement including the reasons as to why HTTP identifiers should be treated as being persistent
TVR: URL shortening services - do they play a role?
JAR: Not part of my thinking so far
... scheme-agnostic approach would include specification of mappings from p.i. scheme URIs (e.g. doi) to equivalent HTTP URIs
... status quo is worse than either of these alternatives
<timbl_> We could do both of the above. Because even ig you allow a limit ednumber of doi: type things with defined maooings, yo have to look afte the persistence of many other http: things fro communities who just use the web and don't want to do doi:
JAR: sources of distrust
... i) authoritative behaviour in HTTP is defined by protocol, not "social contract"
... ii) domain names are defined by IANA, where persistence is not considered a core value
... iii) The Web is relatively new and still considered as part of the "wild west"
<timbl_> so the tage should rage agsint inconsitency
JAR: TAG can argue for things that increase trust in HTTP
<timbl_> http://www.w3.org/Consortium/Persistence.html
JAR: (describes options from slide on 'Arguing for trust')
... risks:
... too hard to influence IANA/ICANN
... hard to convince others to trust it
... build it, but no-one uses it
<timbl_> You can replace the root DNS server in yoru local area with a persistent one
<timbl_> You can make a whitelist of sites which are deemed persostent and have a scobdary parallel lookup mechanism
JAR: risks of status quo
... increasing demand leads to increasing inconsistency
... what can we do to advance this decision process?
<Zakim> timbl_, you wanted to talk for 45 mins why the publishing industry doesn't buy it
<jar_> timbl: Do both
TBL: should do "both" (pursue both DOI and similar AND also HTTP persistence)
... if you are going to have DOIs or other schemes, should include a requirement that there is an algorithm for mapping for returning a "pdf" (or other document)
... would like to have the .arc implemented
<raman> Noah, I'm having Rohit come over and be here in my stead, need to run to a meeting -- back by 11:40
TBL: note Mutual Aid
... (via Jonathan Zittrain)
<ht> seems v. close to ARK to me
<timbl_> .ark
<ht> (John Kunze)
<Zakim> timbl2, you wanted to suggest requiring an urn to http algorihm to be REGISTERD whenever a urn scheme is ucreated
<Zakim> timbl3, you wanted to medntion mutual aid
<Zakim> ht, you wanted to argue against the scheme-agnostic reference approach, based on JISC consensus
HT: can make the scheme-agnostic proposal stronger
... based on London meeting - proponents of alternative schemes all signed up to a statement -
... best way forward is that anyone who pubs refs should publish HTTP references (either alongside, or instead of any other reference)
... so we can legitimately endorse publishing mappings from other schemes to HTTP URIs
<ht> [E]nsure that actionable http URI manifestations are available for
<ht> any non-native http URI identifiers.
NM: formally welcomes Rohit Khare as substitute for Raman
JAR: troublesome part is references where you publish both a DOI and an HTTP ref
... RDF is also troublesome - don't usually give a URI and then metadata for use of that URI
... lot of pressure to improve the metadata and annotation in scholarly articles
... ORCID trying to solve the problem of interop between publishers to allow "federated" pub search
HT: we still need a staged approach
<ht> In actionable contexts, use the actionable manifestation
AM: suppose we agree - who are we reaching out to? What are we recommending?
JAR: growing number of groups are confused about this
AM: Should W3C take a very public position about this?
JAR: doesn't necessarily require a big W3C investment
... TAG could make a statement
... NSF, ORCID, others
... a TAG statement could be used to support best practice within these communities
HT: would lead to internal discussions within places like XRI, other communities about such a W3C statement
<Zakim> noahm, you wanted to ask why the "do HTTP" option was presented so hesitantly
NM: would like to make a very positive statement about the use of HTTP URIs, if we make any such statement
<Zakim> ht2, you wanted to endorse the status of namespace URIs as rigid designators
<Zakim> ht3, you wanted to say we could also try to 'fix' 3986
<tvraman-prime> [er, speaking as Rohit] an aside: "compact persistent identifiers" may be confused with "url shortener" in public PR. TAG isn't taking a position on those, is it?
<noah> raman-prime: That was mentioned before you turned into TV, I think, but thanks for catching it.
HT: "are URIs really names?"
... XHTML NS URI remains in perpetuity because of how it is defined, and how it is used
... actually seems to be the case that it is important that you don't need a 200 response from that URI
... meaning not tied to the status code when doing a GET
... so fix RFC3986 - it's not what you retrieve from it (the URI) that defines what it (URI) means
... URI owner says what the URI means
... it's the RDF around the use of a URI that determines what it means
TBL: I don't think it's people's websites wrong that is the problem - it's about the problem of the website going away'
<Zakim> timbl_, you wanted to discuss long res in particular lables on RDF link sgoing out of a dataset e.g. a foaf file.
<ht> "protecting" domains and being clear about what constitutes a 'normative' definition of the meaning of a URI might be a productive thing to do
HT: you are right Tim - so the proposal to protect some domains should be linked to this, and the link/mapping should be normatively defined
... either new TLD or "protect" some set of current domains
TBL: good to give not only URI, but also a human-readable label (in FOAF) and perhaps also what class it is
... URI can then be better-interpreted by intelligent things like human beings
YL: owner of URI is giving a social contract - W3C does already do things around this (DTDs for example)
... the fact that you can de-ref a URI by getting the document from local disk is important
<timbl_> "If you get a 200 then it is authoritative" vs "To know what this means you must look it up and get 200"
HT: "this (local) copy is just fine"
TBL: I can never know what this means without a MIME type
NM: would it be worth a TAG finding discussing the difference between these two statements (200 is authoritative vs. to know what this means you must look it up and get 200)
?
<jar_> timbl: The subtlety of HTTP authority is one point that gets in the way of 'Just say http:'
HT: "if we deliver something with a 200, then we warrant that it is authoritative"
<jar_> ht: If you get a 200 _from us_, then *we warrant* (we the domain owner) that the response is authoritative
ACTION-444
<noah> ACTION-444?
<trackbot> ACTION-444 -- Jonathan Rees to draft a white paper on link persistence -- due 2010-10-11 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/444
JAR: I believe this action is met by my memo
<noah> close ACTION-444
<trackbot> ACTION-444 Draft a white paper on link persistence closed
ISSUE-50
ISSUE-50?
<trackbot> ISSUE-50 -- URIs, URNs, "location independent" naming systems and associated registries for naming on the Web -- open
<trackbot> http://www.w3.org/2001/tag/group/track/issues/50
TBL: (discusses decision tree diagram on board)
... would like a finding that describes the decision tree
... and then add related action items
... keep a map of DNS (archive foundation)
... build a system to route around DNS-related problems
... TAG investigation on actual R&D making machine-readable mapping from schemes to HTTP URIs
... convene an "action group" to move this forward
HT: should move forward from the London workshop - we still need help from the outside to get things done
<noah> . ACTION: Henry to organize meeting on persistence of references due: 2010-02-28
<noah> ACTION: Henry to organize meeting on persistence of domains due: 2010-02-28 [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-477 - Organize meeting on persistence of domains due: 2010-02-28 [on Henry S. Thompson - due 2010-10-27].
HT: 'protect domains' issue is one where we need more people
<DKA> Image of white board: http://www.w3.org/2001/tag/2010/10/PersistenceTreeWhiteBoard.jpg
HT: other action - some willingness to make a policy statement, so let's make a TAG statement endorsed by others
JAR: who do we want to endorse such a statement?
HT: (adds statement to board - "use actionable HTTP manifestations of non-natively actionable URIs in actionable contexts")
<noah> . ACTION: Jonathan to prepare a first draft of a finding on persistence of references, to be based on decision tree from Oct. F2F
HT: this is more than defining the mapping
... requires also performing the mapping
<noah> ACTION: Jonathan to prepare a first draft of a finding on persistence of references, to be based on decision tree from Oct. F2F Due: 2010-01-31 [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-478 - Prepare a first draft of a finding on persistence of references, to be based on decision tree from Oct. F2F Due: 2010-01-31 [on Jonathan Rees - due 2010-10-27].
NM: scheduling choices:
... propose we take a 15 min break, and then start up with web apps
ADJOURNED
http://www.w3.org/2001/tag/2010/10/19-agenda#WebApps
NM: this session should talk about "what are we doing here"
... switching to do privacy first
NM: workshop coming up in December on this topic: http://www.iab.org/about/workshops/privacy/
<noah> ACTION: Noah to Ping Thomas again on Dec. Privacy workshop [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-479 - Ping Thomas again on Dec. Privacy workshop [on Noah Mendelsohn - due 2010-10-27].
DKA: I think we should have a focussed discussion about Evercookie
ACTION-460?
<trackbot> ACTION-460 -- Daniel Appelquist to coordinate with IAB regarding next steps on privacy policy -- due 2010-10-12 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/460
DKA: talked to organizers of workshop about relation between TAG and this workshop
... this is an ongoing thing - we need collaboration between TAG and IAB
... first thing is this workshop
<noah> ACTION-460 Due 2011-01-20
<trackbot> ACTION-460 Coordinate with IAB regarding next steps on privacy policy due date now 2011-01-20
AM: there was a privacy workshop last month? (link?)
<noah> AM: There was a report by Rigo from the previous workshop
<DKA> Privacy Workshop Agnda: http://www.w3.org/2010/policy-ws/agenda.html
<DKA> Nick Doty's paper: http://www.w3.org/2010/policy-ws/papers/03-Doty-Wilde-Berkeley.pdf
<noah> JK: Dan, are you representing the TAG at the IAB workshop?
<noah> DKA: Won't be there.
<noah> DKA: I'm on the PC, but won't be there.
<DKA> The IAB workshop is Wednesday, December 8 Thursday, December 9
<noah> JK: Is this our first chance to follow up with IAB et. al on privacy work?
<noah> DKA: Well, it's not a manifestation of a formal plan to coordinate, except insofar as I, a TAG member, am on the program committee
NM: should we list some goals for TAG work on privacy, or just put this as a background issue?
DKA: evercookie makes the association between HTML5 and a lack of privacy
... my view is that we should push back on this issue generally-speaking
... it behooves us to associate HTML technologies with an *increase* in privacy
... push people to improve privacy in specific ways
... evercookie is about exploiting the cracks in system boundaries
<Zakim> noah, you wanted to say I'd like to think about deeper implications of evercookies
NM: I'd like to look at the deeper issue exposed by evercookie - even if you do something good with the formally-defined storage mechanisms available...
... have we created a system where we cannot ever *really* protect you?
... here is what it means, and here the tradeoffs...
... here are the all the things one can do to mitigate privacy problems on the Web
AM: cient-side storage work says that you "ought to be able to delete cookies in any way necessary"
... proposal was made that this should be supported by vendors but there was pushback
(see link: http://lists.w3.org/Archives/Public/www-tag/2010Aug/0030.html)
DKA: (writes a list of "privacy invasive" techniques used in evercookie work on board)
... "we can't fix it because it's an arms race" position
list comes from the evercookie paper - http://samy.pl/evercookie/
<noah> JK: I have a lot of sympathy with Noah's view here
<noah> Hmm. Noah sees he wasn't scribed.
<noah> Ah, was earlier.
<Ashok> Cookie storage mechanisms:
<noah> JK: Yes, we can deal explicitly with some of the bits n pieces, but I think it's important to acknowledge that we are likely to be leaving holes.
<Ashok> - HTTP Cookies - Local Storage Objects (Local Storage Objects) - Cookies in RGB values using canvas to read values back out - Storing coolies in Web history - HTML5 Session Storage - HTML Global Storage - HTML SQL Storage - CSS Storing visited state - DOM Form fillin
<noah> DKA: That's a whole topic that's up for debate. I'm receptive/positive on CDT proposal, which are about storing and carrying metadata about privacy with data as it moves through the system. BUT: this isn't about that.
<Zakim> johnk, you wanted to note sympathy with Noah's opinion
AM: there are these 3rd party browser plugins which stop scripts (for example)
... they also decrease functionality...
NM: some of this is about what you visit, not what you publish
RK: "these 4200 websites are all owned by Viacom" (on same-origin policy)
... worry about the effect of trying to make a TAG policy statement about something still so unsettled
<Zakim> noah, you wanted to repeat myself
RK: alternative might be to make specific statements like "add a privacy considerations section to specs"
NM: could make statement saying "when you use the Web, this is what is possible" - "you should assume that your tracks on the Web will be followable and correlateable"
... and/or "these things become urgent good practice in order to prevent privacy problems"
<DKA> For example, we could say about this: "techniques [evercookie] have been developed to circumvent users' privacy preferences through exploitation of cracks 'between' w3c standards (canvas, web storage, css, etc...). The specific exploits are x, y, z. We recommend that a, b, c working groups address these issues and work with the TAG to ensure that these resolutions mesh with eachother to help protect user privacy."
RK: perfectly reasonable for TAG to say "these things have issues"
DKA: would not want the TAG to say "this is a solution to this or that"
... make a recommendation to W3C WGs that they attempt to address specific issues exposed by (for example) evercookie
<noah> And my concern is: is the list DKA gives likely to be sufficiently bounded, or slowly changing, that we can achieve having "the resolutions mesh with each other to help protect.." I'm not convinced we aren't engaged in false advertising if we promise that.
TBL: reasonable for the TAG to look at this...
<Yves> http://www.ietf.org/proceedings/77/slides/plenaryt-5.pdf
TBL: will there be social pressure on the community to fix this (rather than technical solutions)?
... such pressure may lead to technology that helps
<DKA> Rohit said: "unintended persistent data storage with lack of user control"
RK: unintended persistence (uncontrollable) data storage with lack of user control
NM: will you (a user) be able in general to distinguish the items which you need to control?
... I can delete my entire local email storage in order to prevent tracking through that, but this seems extreme
... have the TAG give a "health warning"?
RK: "the following pieces of data are possibly persistent and may be used to track a user across the Web"?
... here's what a UA may persist
DKA: we're not saying that there is any guarantee of user privacy, but we should take a stance on this situation
NM: don't want this to be "false advertising"
<tvraman-prime> [speaking as Rohit again, sorry] Would love to be able to point developers and advocates at a document that says "A Web user agent may persist user data in the following ways, some of which are clearly documented, any of which may be desirable or undesirable"
TBL: can you build a sandboxing technical solution?
HT: I have such a sandboxing solution that filters all outgoing traffic and prevents information from leaving the machine
<tvraman-prime> Mozilla has a plan to stop CSS History sniffing -- do they need TAG help? http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/
NM: how can you possibly filter *everything*?
<tvraman-prime> DKA cited: https://panopticlick.eff.org/
<ht> The tool I'm referring to is http://sandboxie.com/
JAR: Safari private browsing deals with the evercookie script
YL: can taint data based on its origin
... and put policy around that...
<ht> Hmm, seems I was over-optimistic -- sandboxie protects you across sessions, but not, maybe, within a session
JK: mentions sandboxing work in Chromium, Webkit2 et al
<Zakim> jar_, you wanted to think aloud about privacy law and policy disclosure statements - maybe apply idea to browsers?
JAR: thinking of paper privacy statement information (as mandated in HIPAA, other law for example)
... what would happen if you put such privacy statements in UAs?
... privacy disclosure statements
RK: wary of making statements which might make software "accountable"
TBL: lot of interest in making such statements (as noted in previous workshop)
... privacy statements are not kept in sync
<jar_> That doesn't work.... if the browser vendor made a privacy policy statement, then they could be held to the statement, and held accountable... would only happen if compelled to... same issue as a software warrantee, would never happen.
TBL: it is not true that you can put anything in an HTTP header without accountability for it
<DKA> to be clear: I am not suggesting that the TAG can solve the user privacy issue (whatever that may be).
TBL: but if you sign something you can be legally held accountable
<Zakim> DKA, you wanted to suggest we not try to re-invent p3p
DKA: suggest we don't try and fix the big issue of user privacy
(TVR joins)
DKA: should point out that this is an architectural issue
RK: retrievable privacy policies (such as P3P) are not kept up to date - no industry around that
<Zakim> noah, you wanted to try to focus on goals and next steps
NM: what should we do, concretely, about this? Concrete steps please
<Zakim> masinter`, you wanted to refine DKA words
<DKA> reposting for larry: mple, we could say about this: "techniques [evercookie] have been developed to circumvent users' privacy preferences through exploitation of cracks 'between' w3c standards (canvas, web storage, css, etc...). The specific exploits are x, y, z. We recommend that a, b, c working groups address these issues and work with the TAG to ensure that these resolutions mesh with eachother to help protect user privacy."
LM: I'm sceptical about going down this road
<noah> NM: Specifically, I'd like people to propose: 1) what should be the goals of the TAG's further work in this area be and 2) what, therefore, are the concrete steps we should take to achieve those goals
DKA: specifically talking about evercookie
LM: user is trying to accomplish something - clearing the data doesn't necessarily do that
... reluctant for the TAG to endorse a technical solution that we don not think actually solves this problem
NM: what can we do at this technical (very low-level) level to have a real world effect on something less technical (user privacy)?
... if result is that much less information is leaked then great
... ... but if not, should we really say something?
AM: idea of a "health warning" is reasonable and a good idea
<DKA> The word on the street: New Web Code [HTML5] Draws Concern Over Privacy Risks : http://www.nytimes.com/2010/10/11/business/media/11privacy.html
AM: Dan mentioned these things come from different W3C WGs - but this is NOT only a W3C issue
... if you say "this tech has a problem" but they will say "this work is also useful"
<Zakim> johnk, you wanted to note that we should not stand in the way of evercookie of other things which dramatically highlight these issues
<noah> JK: The publicity from things like Evercookie is more effective than anything we could do; therefore we should do nothing to stand in the way, and leave the public relations to efforts like that.
<raman> lunch beckons
<noah> Lunch is on the agenda for 12:15 -- Rohit said that would be OK. Is that a problem after all?
ADJOURN (for lunch)
<noah> http://www.w3.org/2001/tag/2010/10/19-agenda.html
<Larry> scribenick: Larry
(discussion of agenda)
topics XML/HTML integration, action-476, admin session, jaffee gouls, action-448, web app architecture
NM: we haven't made enough progress on webarch, do you really believe the goal that we're going to get organized
LM: I think we're making good progress on this long-term goal, but we are giving 5 things 20% service
NM: not scaling, people aren't vesting enough
TVR: we need to leverage the external community better, the 9 of us don't know enough, and there's going to be turnover. This is my last tag meeting, i am not going to be a TAG candidate.
... the tag has been around for 9 years, there are people who have valuable input
(discussion of individuals, former tag members, who have valuable contributions, have helped, etc.)
NM: raman invited to next TAG meeting
TVR: i hope to be able to contribute to the TAG in the future; continuing, that level of involvement should be encouraged
AM: we have a table of contents, ask people to write sections of that. Noah: we did that. Ashok took storage.
... Larry's email was useful, make be can expand that
<Zakim> johnk, you wanted to mention one technique for getting real stuff done
JK: as part of my action items on this, i thought of 3 examples of new interaction modes.... one thing that I found when doing that work, related to jonathan's work... I'm still unsure about what exactly is new here. The mechanism by which individuals write something and others critique it, isn't going to get the job done.
... (discussing how he gets security threat analysis written)
NM: what we've been missing has been what the tag wants to say
TVR: that's top down, doesn't work. the whole model of individuals writing & reviewing doesn't scale, it's still only 9 people
NM: we only occasionally got comments, the blog has been useful but not given the next level
<Zakim> jar_, you wanted to consider utility of threat model
JAR: this "web application" things has been bothering me because it seems amorphous, but nobody seems what it good it will do. I've been thinking about threat models as a perspective. What are in danger of losing? The web architecture document had some of that. Because it looked like it was under siege, and we were defending it. Just suggesting as a heuristic.
<Zakim> Larry, you wanted to suggest more interim publications of draft TAG documents for community review, rather than waiting for TAG to be "done"
JAR: we talk about the W3C mission and good properties and ways in which the web can be made better -- if you think of it as a defense rather than a scholary survey, that might help.
<noah> LM: I want to advocate more frequent publication of smaller, interim documents, that we're not done with, for public comment.
<noah> LM: There's an early stage where you get a first level of comments, we can have an effect on the community even from the interim state
<noah> LM: We could have a goal of having one blog entry a week.
<jar_> LM: suggest documents that are not just an individual's musings, but a report on the TAG's current thinking on the topic
<Zakim> johnk, you wanted to advocate a "blunt instrument" approach
<Zakim> noah, you wanted to talk about threats
NM: i liked what JAR said about threats -- first webarch doc was a "hey wake up". That's what I assumed what we were doing. Personally, I have a list of threats that have come up in context.... "How far do the good characteristics of the REST model stick around when you have javascript munging URIs"
TVR: minutes 10 years ago were a way of engaging the community; now the minutes aren't sufficient
<Zakim> Larry, you wanted to talk about tweeting too
LM: also I tweeted and got re-tweeted, which i thought was some interesting feedback
<noah> NM: I think that happened not primarily because you wrote a blog entry as opposed to TAG Finding draft; you were retweeted because what you wrote was well crafted, and thoughtful.
TVR: why haven't we done it?
JK: lack of time to do focused work of that much length .... schedule time to do work, do writing in meeting
NM: 8 people per hour working on commas
(discussion about how to organizing writing sessions)
NM: next f2f is in 3 months, is this something we can do on phone?
TVR: this is something we did in xforms -- kept zakim open, everyone sat in their location and worked on their documents, did this for 8 hours
... everyone sitting in their own environment doing the writing, everyone else committed to reviewing immediately
<Zakim> DKA, you wanted to support John's "just do it" approach.
<Zakim> Larry, you wanted to suggest concrete steps to do more and publicize what we've done
DKA: has many of the same issues, would help. Timezones do crop up
TVR: email & wait for review is completely asynchronous, f2f is completely synchronous, i'm suggesting something in between
DKA: if you organize it enough, you can do it early morning, late evening
<noah> LM: Offers to host a session on the MIME and the Web document
<noah> TVR: 3 hours is good
<Zakim> noah, you wanted to talk about time
NM: scheduling a 3-hour session before there's a first draft is questionable
... people have to think about the amount of time they have on time work.
... the process on webarch was painful, half-time for 6 months. people used to do things on that scale, seeing less of it.
... the format is only a piece of the puzzle, people need to make a commitment
<johnk> http://lists.w3.org/Archives/Public/www-tag/2010Oct/0061.html
AM: I'd propose http://lists.w3.org/Archives/Public/www-tag/2010Oct/0064.html as an introduciton to the WebApps chapter of WebArch
JK: Roy Fielding's description, pointer to CREST was an interesting perspective
<Zakim> Larry, you wanted to point out that we could take the emails on the mailing list and use them in documents.
<johnk> LM: need to pull out the really important statements from some of these email threads
<Zakim> noah, you wanted to talk about email
NM: we used to have a tradition that went beyond that, where poeple were encouraged in email to express their opinions by expressed new text in a document... if you don't like what i said, put it in a form you think would work
... to go back to the particular several efforts on which we have actions... now that i've heard this, i know what i want to do
HT: I want to take a 'glass half full' view... people who have been working have been making progress. I would like to 'spin' what we're getting toward as "let's put all of our effort toward helping the people who are making progress". We are much closer to the event horizon with webapps than we were when we started webarch
NM: no one is saying "let's stop working on webarch", various flavors "glass is half full, progress we've made isn't so bad, let's team up to move more effectively"
(discussion of Raman/Ashok on client side state, client side storage)
<noah> ACTION-430?
<trackbot> ACTION-430 -- Ashok Malhotra to propose a plan for his contributions to section 5: Client-side state -- due 2010-09-09 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/430
TVR: ashok, would you take the edit token on hash-in-URL document
AM: BBC situation
TVR: The BBC conversation -- there were parts of BBC site that were obfuscated because they didn't want their content scraped and reused.
... the URL of the content stream was obfuscated
<noah> ACTION-430?
<trackbot> ACTION-430 -- Ashok Malhotra to propose a plan for his contributions to section 5: Client-side state -- due 2010-09-09 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/430
AM: we're trying to create one document so we can all discuss
<noah> LM: I still want to get things out to the community earlier through blogs, etc.
<noah> NM: Not the www-tag list?
<noah> LM: Not good enough. Too hard for people to find what they need.
HT: i disagree, most nobody has enough time. I disagree -- it sounds like you're asking for more things to be done
<Zakim> DKA, you wanted to wonder if we need another meta-level note on webapps arch - could just collect discussion on action-434...
HT: if webapps architecture is our ongoing goal, writing deliverable prose should be our focus
dka: there's another document, around action-434
action-434?
<trackbot> ACTION-434 -- Daniel Appelquist to prepare discussion of structure of what we want to do about web apps architecture... -- due 2010-10-18 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/434
<DKA> http://lists.w3.org/Archives/Public/www-tag/2010Oct/0068.html
NM: I don't know if it's useful to go top down
... maybe we could go bottom up
http://www.amazon.com/Scrolling-Forward-Making-Documents-Digital/dp/1559705531
NM: Yves, how many people subscribe to www-tag?
YL: 240 subscribers
<Zakim> noah, you wanted to talk about www-tag
<Zakim> timbl, you wanted to ask whethre it should be or main goal
TBL: what should be the top things the TAG is working on?
... Is WebApps an area where we have enough coherent to say yet? The story on persistence is importance?
(discussion of TAG report at TPAC)
<noah> http://www.w3.org/2001/tag/2010/sum07.html#html
<noah> That's the TAG's July report on HTML 5 progress/impact:http://www.w3.org/2001/tag/2010/sum07.html#html
<Zakim> Larry, you wanted to point out that top down and bottom up are not exclusive but are coordinated
<noah> LM: I believe we can go top down and bottom up
TVR: think the conversation has been productive
NM: (wrap up discussion)
... big priorities vs. little priorities. balance top down & bottom up. thoughts about how to publish. go through actions: for each of them, are we happy with what's happening next?
AM: on the client side state & storage: I will revise the documents based on comments. I would then like a telcon, that's the one i'd like to start on.
NM: how about one at a time to pick up on these, ask the tag at a whole, look at the writing, and then try to do at least one well. Try to get everyone's priorities set.
AM: there was another idea here to write an intro based on some email?
<noah> ACTION: Appelquist to draft overview document framing Web applications as opposed to traditional Web of documents Due: 2010-11-01 [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-480 - Draft overview document framing Web applications as opposed to traditional Web of documents Due: 2010-11-01 [on Daniel Appelquist - due 2010-10-27].
<noah> ACTION-430?
<trackbot> ACTION-430 -- Ashok Malhotra to propose a plan for his contributions to section 5: Client-side state -- due 2010-09-09 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/430
<noah> close ACTION-430
<trackbot> ACTION-430 Propose a plan for his contributions to section 5: Client-side state closed
<noah> ACTION: Ashok to update client-side state document with help from Raman Due: 2010-11-30 [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-481 - Update client-side state document with help from Raman Due: 2010-11-30 [on Ashok Malhotra - due 2010-10-27].
<noah> ACTION: Ashok to write a draft on client-side storage with help from DanA Due: 2010-11-30 [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-482 - Write a draft on client-side storage with help from DanA Due: 2010-11-30 [on Ashok Malhotra - due 2010-10-27].
<timbl> http://jeffersonsmoose.org/
<noah> RESOLUTION: Minutes of 7 October 2010 are approved
<timbl> jar, http://www.w3.org/2010/roadmap/tag-goals.svg
<noah> ACTION: Noah to inform TAG of TPAC meeting schedule [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-483 - Inform TAG of TPAC meeting schedule [on Noah Mendelsohn - due 2010-10-27].
<noah> ACTION: Noah to alert chairs, ac-forum, www-tag of TAG availability for Monday session at TPAC [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-484 - Alert chairs, ac-forum, www-tag of TAG availability for Monday session at TPAC [on Noah Mendelsohn - due 2010-10-27].
<Ashok> (discussion of meeting in Cambridge)
<noah> ACTION: Noah to have Amy reserve rooms for TAG F2F Feb 8-10 2011 [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-485 - Have Amy reserve rooms for TAG F2F Feb 8-10 2011 [on Noah Mendelsohn - due 2010-10-27].
<jar_> https://www.csail.mit.edu/mrbs/
<jar_> http://lists.w3.org/Archives/Member/tag/2010Oct/0059.html
<timbl> Explicitly "grandfather" application/rdf+xml by exempting it from
<timbl> generic processing, as a special case. That is, although
<timbl> application/rdf+xml contains the "+xml" morpheme, point out that the referent of URI with fragment identifier are that defined by the RDF/XML specifications.
<noah> Proposed sentence ahead of start of option #2:
<noah> Indicate that media type registrations for media types of the form application/___+xml MUST/SHOULD NOT provide definitions for fragment identifiers that would cause any particular such identifier to resolve differently than per the generic rules.
<jar_> Timbl's formulation of what in IRC was #4 and in email is #2: When the mime type is *+xml, then the semantics of fragment identifiers are defined by the xpointer specification, except for application/rdf+xml where they are defined by the RDF specs.
<timbl> http://www.w3.org/2010/10/19-tagmem-irc.html#T21-42-47
<noah> Explicitly "grandfather" application/rdf+xml by exempting it, as a special case. When the mime type is *+xml, then the semantics of fragment identifiers are defined by the XPointer specification, except for application/rdf+xml where they are defined by the RDF specs.
<noah> Remove "heated discussion", please.
<noah> The TAG resolved that either of the following two approaches would be acceptable, and we would appreciate your consideration of them.
<noah> . RESOLVED: The two technical proposals to generic processing are acceptable, and JAR to mail after editing as per discussion
<noah> ACTION-476?
<trackbot> ACTION-476 -- Jonathan Rees to draft a short note to 3023bis editors reflecting the discussion / consensus... -- due 2010-10-26 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/476
<noah> ACTION-466?
<trackbot> ACTION-466 -- Larry Masinter to ask Norm, Roy and Martin for concrete use cases where generic processing of fragment ids is important -- due 2010-10-12 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/466
<noah> close ACTION-466
<trackbot> ACTION-466 Ask Norm, Roy and Martin for concrete use cases where generic processing of fragment ids is important closed
<noah> ACTION-448?
<trackbot> ACTION-448 -- Noah Mendelsohn to schedule discussion of http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html on 26 August (followup to 24 June and 12 August discussion) -- due 2010-10-12 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/448
<noah> close ACTION-448
<trackbot> ACTION-448 Schedule discussion of http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html on 26 August (followup to 24 June and 12 August discussion) closed
<timbl> http://www.w3.org/2010/roadmap/tag-goals.svg
<noah> ACTION: Noah to schedule group discussion of goals and roadmap for metdata work [recorded in http://www.w3.org/2010/10/20-tagmem-irc]
<trackbot> Created ACTION-486 - Schedule group discussion of goals and roadmap for metdata work [on Noah Mendelsohn - due 2010-10-27].
