See also: IRC log [incomplete]
<noah> http://www.w3.org/2001/tag/2012/09/20-minutes
RESOLUTION: minutes of 2012-09-20 approved
<noah> http://www.w3.org/2001/tag/2012/09/27-minutes
RESOLUTION: minutes of 2012-09-27 approved
<noah> http://www.w3.org/2001/tag/products/index-2012-09-26.html
<noah> http://www.w3.org/2001/tag/products/index-2012-09-26.html
Noah: for Fragment identifier document, do we need CR?
Yves: yes CR is mandatory as you must prove interoperability (technically, CR can be skipped if there is evidence)
Larry: the specification contains
lots of recommendations for media type registration for
example
... happy to change the REC date to be the CR date (then wait for
"implementation" evidence)
Ashok: we need to spell out the exit criteria
Larry: as it can be implemented, we should go through CR
Yves: we can already have implementation, so we need first to outline the exit criteria
Noah: we need to have an action to create exit criteria
<JeniT> ACTION: Jeni to with Larry work out what the exit criteria from CR for fragids best practices should be [recorded in http://www.w3.org/2001/tag/2012/10/09-minutes.html#action01]
Larry: we need to put attention to steps that engage the community, so it makes sense to push our schedule to accomodate communicating with the community
Publishing and Linking
Noah: someone working on starting a community group?
Larry: wondering if it is the right step
Ashok: what are the exit criteria here?
Yves: is REC the right track? shouldn't it be a TAG finding?
Larry: when we put the schedule together, we had best practise in the document. We moved incrementally best practises out of the document
Noah: we promised a REC, we may have now more insight and decide that it was not the right format
Larry: we will do another editorial pass on the document. Thinking of the exit criteria after the next iteration is a good idea
<noah> ACTION: Larry with help from Ashok (and TAG), 1) decide exit criteria on Publishing & Linking 2) Rec track vs. Finding 3) Update product page to match - Due 2012-10-16 [recorded in http://www.w3.org/2001/tag/2012/10/09-minutes.html#action03]
URI Documentation Discovery
product page should be updated before TPAC
Noah: there are also lower priority items that might (or not) become higher priority topic
Ashok: Web application storage should be transformed into offline applications, we will then decide what to do with it
JeniT: we might look at distributed web applications, with data exchanged between different services (at different locations)
about registered protocol handlers, web intents, and accessing your own data from an online service
(can be tied to open data)
Ashok: will it involve synchronization?
local data to global data
Tim: it's an independant problem
Noah: is the TAG interested in this
topic, and should Jeni work on a more detailed proposal?
... yes
Tim: another interesting thing is to look at a specific technology or topic and find out what are the missing pieces
Larry: how do we update the architecture document to match what people need
<JeniT> ACTION: Jeni to draft rough product page / briefing pape for "distributed web applications" [recorded in http://www.w3.org/2001/tag/2012/10/09-minutes.html#action04]
Noah: it is good information to have a timeline and the kind of document we want to produce
Jeni: do we need to change the arch doc wrt issue-57?
Noah: the goal by itself is not updating webarch
<masinter> perhaps we need to add, before we close an item, to review webarch & web presence
Larry: before we close an item, we should add another step: go back and update webarch if needed
keep this an alive document
Noah: the goal of a topic is not to publish a document but to help the community, we failed to get input from the community one year after to see if it helped or not
ht: I agree with Tim, AWWW is an historical document.
NM: Maybe I should come up with a plan for going over our recently closed work to check on whether success criteria are being met
ht: the world moved on, with new complexities
<noah> ACTION: Noah to think about how to evaluate results vs. success criteria on closed work - Due 2013-01-01 [recorded in http://www.w3.org/2001/tag/2012/10/09-minutes.html#action05]
<Zakim> masinter, you wanted to add 'persistence' and 'security infrastructure & architecture' as potential projects
Larry: persistence of identifier is too narrow, persistence of document is important
LM: Not sure I have time to lead this
Larry: we need also work on security
Ashok: who should work on that?
Noah: who wants to work with the security community to figure out where the TAG could be helpful?
<noah> ACTION: Ashok working with experts in security community, to suggest projects TAG might undertake relating to security - Due: 2012-11-20 [recorded in http://www.w3.org/2001/tag/2012/10/09-minutes.html#action07]
Noah: we should go through our issue list and check if there are issues we could make progress as work items
larry: dwim?
Noah: it would be good also to strongly promote the "be conservative in what you send" part of Postel's law
<masinter> http://www.w3.org/wiki/Evolution
<masinter> A third rail is a method of providing electric power to a railway train, through a semi-continuous rigid conductor placed alongside or between the rails of a railway track. It is used typically in a mass transit or rapid transit system, which has alignments in its own corridors, fully or almost fully segregated from the outside environment. In most cases, third rail systems supply direct current electricity.
Larry: error handling is part of the theory about managing evolution. should be on the list of candidate topics
<masinter> there is a debate in the W3C community about how to write specifications, which is whether you specify a narrow normative language and leave it implementation-dependent how to handle it
<masinter> http://masinter.blogspot.co.uk/2011/06/irreconcilable-differences.html
<noah> ACTION: Larry to frame for telcon discussion possible TAG work relating to DWIM and Issue errorHandling-20 - Due 2013-11-13 [recorded in http://www.w3.org/2001/tag/2012/10/09-minutes.html#action08]
<masinter> on long-term permanence, see http://larry.masinter.net/0603-archiving.pdf
<noah> ACTION-725?
<trackbot> ACTION-725 -- Jeni Tennison to with help from Peter, to create big picture overview coming out of analysis of TAG effectiveness -- due 2012-06-21 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/725
<noah> Objectives matrix: http://www.w3.org/2001/tag/doc/objectives-matrix-20120930
<noah> From the intro to the matrix: "http://www.w3.org/2001/tag/doc/objectives-matrix-20120930"
<noah> From the intro to the matrix: " If it were 1988 and one had to design the Web, what would the design objectives be?"
Jeni: it is important to look at the big picture, and assess how effective we are in improving the web. not had time to flesh out a proposal
Jeni: it is an important thing to do, we might also come back to it after the election
LM: Remind me where we stood with the June session
NM: Jeni and Peter took action to distill. Still good to do, no progress yet.
Noah: there might be discussion with the AB at TPAC, ready to facilitate such a meeting
<noah> ACTION: Noah to send Steve Zilles note saying Henry, Larry, Peter, Ashok, Tim and Jeni (Wed) could meet with AB [recorded in http://www.w3.org/2001/tag/2012/10/09-minutes.html#action09]
<noah> 4 min timeout to review: http://www.w3.org/2001/tag/doc/objectives-matrix-20120930
discussion
timbl: this is an incredible amount of work that jar has done
tbl: it's nice also that it ties
these to our issues
... the objectives were taken by scraping them out of the
document
... did these grow into properties of the web, do they group into
high-level goals or properties of the web?
... some of the ones about extensibility can be grouped
together
noah: this is a good piece of work,
but it doesn't talk to the areas where we are having trouble.
... what we fail to do is bring the community together
... i don't think fleshing out this matrix is going to convince the
community
... we're not respected, how do we fix that
... this is potentially useful, but even in areas where we know
stuff and articulate it well
...we aren't getting the traction we should.
jeni: i think it's a two-way process. This matrix is about, one of the things we talked about was expressing "Why Architecture is Important", these could be grouped together
Jeni: the matrix can be used to
define what are the main goals for the web
... i.e. explain why the architecture is important
larry: to be effective starts with picking the right item to work on, do a good work, then promote it. in this multi-stage pipeline, the matrix is about one part of it.
timbl: the tag tries to define good architectural principles, architecture of the web, and also work on crisis.
noah: we published a finding a while ago on webapps state. I have nor heard back from the community about it and I don't see how the matrix is helping us here
<jar> ummm... the matrix helps because it says we ought to know the objective(s)... ?
<jar> ... or because it provides a list of candidate objectives? ...
larry: what would be the exit criteria for application state? (if it was on REC track) we might review our finding in the light of "what would it take to go to REC", or "should it be obsoleted"
<masinter> "implementation" of findings might be "W3C recs that recommend or reference (or could reference)" ?
timbl: some document might need a push (like going to WGs to talk about it)
<masinter> http://www.w3.org/2001/tag/findings
Noah: the 'success criteria' should not be 'publish a document' (and we tried to stay away from that)
<masinter> benchmark TAG against IAB?
<noah> ACTION-757?
<trackbot> ACTION-757 -- Noah Mendelsohn to think about how to evaluate results vs. success criteria on closed work -- due 2013-01-01 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/757
<Zakim> noah, you wanted to talk about communcation vs. recs
JeniT: on 'managing the crisis', we need to be more reactive where people are actually arguing rather that be only in the mode "this looks interesting, I want to work on this"
<Zakim> JeniT, you wanted to talk about outreach
Ashok: the application state finding is targeted as devs, people we usually don't speak directly to. It would be good to better engage the dev community
<masinter> why don't WG chairs ask TAG for advice on disputes?
<Zakim> noah, you wanted to ask whether we should work with AB on process changes
noah: do we have ideas on changing charter or the process?
<jar> (re "targeted at devs": there is little that individual developers can do or not do to "lead the web to its full potential". rarely they can "innovate". being a "good citizen" doesn't scale. usually potential is advanced and preserved through consensus, and that means WGs)
[DKA joins]
peter: the css wg brought issues in front of the tag, would be happy to have TAG answers being more formal
<noah> LUNCH BREAK
ht: if the +suffix definition for a
fragid doesn't resolve to a fragid, then a specific media type can
take over to provide a definition
... question is whether this (should) only apply to barenames, or
to all fragid syntaxes
... eg in +xml, to XPointer syntax fragids
... if it did apply to all XPointer syntaxes, what would that
mean?
... XPointer allows multi-part parts with failover
... if you support the scheme in the first part, and it defines a
subresource, then that one, otherwise fall on to the next
part
... syntax of XPointer includes barenames
... looks like three failure modes:
... 1. fragid that doesn't match XPointer syntax productions
... that's declarative based on syntax
... 2. 'doesn't map'
... 2a. unbound scheme prefix
... ie no namespace declaration for the prefix used in the
scheme
... 2b. unsupported scheme
... ie unsupported by particular implementation
... 3. doesn't resolve to a fragment -- scheme-specific, failover
to next part of the XPointer
... XPointer only talks about synactic failure and failure to
resolve
... options for 3023bis: liberal and conservative
... liberal: non-XPointer-syntax fragids or ones that don't
resolve, aren't defined by +xml spec
... conservative: non-XPointer-syntax fragids or barenames that
don't resolve, aren't defined by +xml spec
... non-identifying fragids that match the non-barename XPointer
syntax are reserved
... consider application/schema+xml
... want to identify schema components via the elements that define
them within a schema
... would appear to make sense to use XPointer syntax
... with semantics that identify schema components rather than
elements
... but you could only do that if normal XPointer rules don't give
you an answer
noah: doesn't XPointer always resolve to elements, by definition?
ht: yes, hence application/schema+xml should not use XPointer syntax to point to components
<masinter> IETF process is "rough consensus and running code" -- and this is (should be) standards track, so 3023bis needs to follow IETF rules
JeniT: but if you have a vocabulary that wants to use fragids to point to elements, then...
ht: ...then you define a new XPointer scheme
JeniT: you should include that in 3023bis
ht: yes
masinter: remember to check what implementations are currently doing
ht: yes
... I don't know any implementations aside from norm's and mine and
Mozilla's that support schemes other than element()
timbl: where are the implementations?
ht: I don't know of any XInclude
implementations (which are the main implementations of XPointer)
that work on the client side
... possibly TEI
timbl: no one uses them with XHTML?
ht: no, people only use barenames with XHTML
<masinter> look at http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-impl/
masinter: look at the media fragments URI implementations
<masinter> can you look at http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-impl/#mf-ua-tc test cases too
ht: ok, good idea
http://www.w3.org/2001/tag/2012/10/07-agenda#offline
noah: we have no actions on this
<noah> ACTION-717?
<trackbot> ACTION-717 -- Ashok Malhotra to propose outline for possible TAG document (finding or rec) on architectural issues relating to storage sync, linked data, etc. Due 2012-07-15 -- due 2012-10-10 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/717
Ashok: they're on web storage
<noah> http://lists.w3.org/Archives/Public/www-tag/2012Sep/0009.html
noah: we need to decide whether we
will proceed on something in this area
... we might define objectives in terms of the objective matrix
DKA: I want to highlight the work going on with FirefoxOS
noah: we'll let Ashok frame first
Ashok: we've been looking at web
storage and appcache, and what these two technologies are helping
us with
... and the target is offline apps
... Yves and darobin convinced me that AppCache is not quite right
for offline apps
<Yves> ie: it's not to be used as 'local storage'
Ashok: so we don't have an offline
app architecture
... and it's something that the web should be supporting
... so I started looking at what it would take
... there's very little user control on the offline app and the
global data and how they work
... so I thought we should try to spell out an architecture for
offline apps
... you could write a paper, but it would be better to be done in a
WG, with a spec
... whether we can help make that happen is the question
noah: what's the state of other W3C work on offline apps?
Ashok: the only thing I know about is
AppCache
... DKA tells me there are efforts to make it better
noah: and there's offline storage,
which is also relevant
... web storage
timbl: you say there isn't enough to do an app? what about the financial times app?
DKA: I was going to highlight that as an example of the state-of-the-art
AM: Let's talk about those
examples
... Local storage is a very simple mechanism
... prop/value pairs, no transactions, etc.
... The Web Database idea was meant to be more like SQL, ended up
with what's now called SQLite
... One thing I've thought about doing was moving that to be the
full SQL thing
DKA: Have people seen the FT WebApp
-- it's a very good demonstration of what you can do in iOS
(Android is coming)
... It brings up what amounts to a browser, but with a chrome-less
view
... Once initialized, you can go offline, and it's still usable -- access to all the
articles, with their text and images
NM: How is it working, with proxy cache or some kind of storage?
DKA: Local storage, v. simple
NM: Not proxy cache, not SQLite?
DKA: Neither -- it does use AppCache, which requires a prompt to enlarge the cache, which they prewarn users about
HST: AppCache?
DKA: Assets needed for an app
JT: Manifest gives a list of assets, browsers then downloading all those assets into a special cache (not their normal web cache)
NM: Could I send a link by copying to the clipboard?
LM: I posted an article for Adobe about it:
<masinter> http://www.adobe.com/inspire/2012/02/html5-next-disruptive-technology.html
DKA: Not easy to tell the answers to NM's question, given the UI
NM: I think it matters whether there's a real, reusable, URI there
DKA: We don't know
HST: AppCache vs. local storage?
DKA: AppCache is for the actual articles and pictures; local storage is for the app itself: javascript, icons, boilerplate
NM: Different from GMail 5 years ago? Updates?
DKA: This updates a lot
NM: I mean from the user up
DKA: that happens too
NM: Synchronisation sophisticated?
DKA: Don't know -- not really my point, I wanted to just show what SOA is, and underline that it isn't easy: FT had to buy the company that got AppCache to work well enough to make this viable
<masinter> http://blogs.adobe.com/digitalpublishing/2010/11/martha-stewart.html
<DKA> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Architecture
DKA: Firefox OS is for mobiles: a stripped down linux running the Gecko engine, everything the user sees is at the Gecko level
NM: File system?
DKA: It's there, but it's not user visible as such
<DKA> https://developer.mozilla.org/en-US/docs/Apps/Manifest
<masinter> http://www.w3.org/2012/05/sysapps-wg-charter.html
<masinter> http://www.w3.org/2012/05/mobile-web-app-state/
<Ashok> Robin, who is fixing Appcache? Is there a sketch of the fixes?
<darobin> http://www.w3.org/community/fixing-appcache/
<darobin> sketch of fixes: https://etherpad.mozilla.org/appcache-london and https://etherpad.mozilla.org/appcache
<Ashok> Thanks! Are you hopeful that this will make AppCache good for offline apps?
<darobin> Ashok, yes, I'm hopeful that we can make AppCache useful ... it's dearly needed. My plan is to bang heads together at TPAC and come out with a plan to write up the fix
<Ashok> Robin, Can I join you in the headbanging excercise?
<darobin> Ashok, of course :)
<darobin> Ashok, be warned though that stories of people using AppCache in real life are actually pretty damn scary ... it's not for the faint of heart ;)
<Ashok> Right! I've heard some of the stories :-)
DKA: It supports permission requests, application orientation, regular/privileged/certified wrt access to to APIs
JT: How do you get privilege?
DKA: Signing and an installation
sequence which involves the user, or could be preinstalled
... Certified is restricted to Mozilla and mozilla partners
NM: So no misc. downloaded app could dial?
DKA: Right, but could request access to less crucial APIs
NM: Skype today gives me an installable plugin, which looks like it can dial out
NM: Not sure the user recognises the difference
DKA: The work Mozilla has done is in
my view a descendant of the work we did on widgets -- Mozilla might
not agree
... but it's definitely in the same spirit
DKA: None of this is a work item in any WG
AM: It goes further than widgets did wrt the execution/security model
<DKA> Sysapps: http://www.w3.org/2012/sysapps/
<darobin> SysApps is where the hosted app vs packaged app decision will happen ... this is important, I'd watch
<darobin> Hosted apps sit on the Web, they just have a manifest; packaged apps are wrapped in a container and downloaded (like widgets)
DKA: To clarify: the execution/security model has been submitted to the SysApps WG, but the packaging stuff has not been, at least not yet -- there is some disagreement about where it should go
LM: I thought the primary difference
between the WebApps and SysApps remits were the security
model
... SysApps has to go outside the sandbox, so WebApps said that was
outside their scope
DKA: In Santa Clara there was a
fundamental disagreement on whether a package format was
needed
... Mozilla were opposed, but have since decided it is
needed
... My understanding was whether packaging should end up in WebApps
or SysApps
RB: SysApps isn't chartered to do
anything about packaging
... But WebApps had something, which could be updated
<DKA> Jidgets!
AM: Coming back to next steps -- it looks like some agreement to 'fix' AppCache issues may emerge, so I think we need to wait until TPAC until we see how that goes ahead
NM: So do we need to decide at some
point to engage with "Offline Apps" as a work item, or just keep an
eye on it?
... I'm just worried we need to commit or move on
... I can't tell if this will deliver value or not
AM: Robin, what do you think?
RB: Two reasons to wait to decide: 1) AppCache changes -- will they be patches or a full-scale rewrite? 2) SysApps WG only just been launched, not yet really going on the security model and offline issue
NM: Yeah, but it's overlate to
advance architectural guidance once those basic decisions have been
made
... E.g the role of URIs
AM: TPAC is less than 4 weeks away
NM: OK, but I want to make a firm decision at our next f2f meeting
<noah> ACTION-717?
<trackbot> ACTION-717 -- Ashok Malhotra to propose outline for possible TAG document (finding or rec) on architectural issues relating to storage sync, linked data, etc. Due 2012-07-15 -- due 2012-10-10 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/717
<jar> Are there any namespace or registry issues associated with storage?
<Ashok> JAR, to your question -- I don't think so
<jar> what about spec collision issues?
<noah> which specs colliding with what please?
<Zakim> timbl, you wanted to say that there seems to be an issue for authenticating, for access to some data, both the person and the app they are using. Currently we have systems which
TBL: Security model for phones is
about privileges you give to an app
... Security model for computer is about privileges you give to a
user
TBL: Are we seeing any convergence -- only a given set of people can get certain functionality from an app
DKA: Doesn't latest MacOS have something like this, as a result of influence from iOS? I can install an app on a multi-user system which may not have access to all files?
<masinter> i don't mind having "track" items that we revisit quarterly to see if we're ready to take on major work, and perhaps we should make that a TAG item
<noah> Larry, that's fine, as long as we agree that's what we're doing
<noah> These have always been framed as: let's see if we can spin up a major effort in storage/offline. We keep saying it but not doing it. That's not healthy IMO.
<noah> If we want to agree to revisit regularly without plan for major deliverable, that's OK, and would be managed accordingly.
HST: Windows has had the me/everyone question at app install for a while. . .
<darobin> on MacOS, the Unix permissions system always applies ... you can install for all users but if it's run as you, it will only have access to what you have access to
<masinter> we could have a quarterly deliverable? blog post, "what's happening with 'offline apps' " ?
<noah> Larry, sure, as long as we say that's what we're doing
<noah> The claims have been we're looking at something like a finding, and then we just get this far, rinse and repeat for > 1 year. You were the one who, in Lyons said: if we revisit something >3 times, we should have a goal.
<jar> I see the TAG's business being mainly 3 things: transparency, consistency, and redundancy. (of specs and/or interfaces.) If none of those are at issue here then I don't see that we have much reason to be involved.
<masinter> jar, what about 'completeness' ? if people are nibbling at the edges
<jar> masinter, I might add that to my list, although coverage/completeness seems to be a linear combination of the other three
TBL: I may want to allow DKA access to my contacts, w/o letting him use BadGuyApp to see them, because I know that BGA does bad things with contacts
NM: I don't mind keeping a watching brief, what I mind is not commiting to that vs. writing a finding
<Zakim> masinter, you wanted to talk about scheduling
LM: Couldn't there be a different
kind of deliverable?
... For things we're watching, w/o committing to intervening at the
architectural level
NM: We can do that, we don't need a process decision -- my concern here is on getting agreement on the level at which we take this forward
DKA: I think there is a specific
issue, which is architectural, albeit a small one: should a
packaged webapp implicitly hold greater privileges than one hosted
on the web?
... Seems to me the TAG could give guidance on this
... Needn't be a finding, could just be email to the WG
chair(s)
<masinter> registerProtocolHandler should have the same kind of 'system' priveleges
TBL: My inclination is that zipping should be architecturally indistinguishable from caching, and so should have no privilege implications
NM: There's an install step
DKA: And a signature
<masinter> Signature, virus scan, insure provenence
NM: zip itself doesn't seem like the crucial bit
LM: registerProtocolHandler, wrt its
security model, needs to be treated as if it is an
installation
... because you're making a permanent change
LM: There's no manifest, there's nothing to install, but it's really very similar
RB: Returning to hosted vs. packages
-- I agree that the zip vs. cache point isn't central
... A packaged app isn't allowed to external resources w/o specific
authorization
... It's 'frozen'
... So you're not e.g. loading jquery from elsewhere, where it
might have suffered an injection attack
... So it's the frozen/sealed nature of the 'packaged' app that
matters
HST: So that's why signing makes a difference, because all you're using is what was signed
NM: So next?
DKA: Should we send something back to SysApps?
NM: Decide now about rolling monitor, or eventual finding, or wait to decide after TPAC
AM: wait to decide after TPAC
<masinter> Dan, what would we send to SysApps that would be useful?
<noah> ACTION-717?
<trackbot> ACTION-717 -- Ashok Malhotra to propose outline for possible TAG document (finding or rec) on architectural issues relating to storage sync, linked data, etc. Due 2012-07-15 -- due 2012-10-10 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/717
<noah> close ACTION-717
<trackbot> ACTION-717 Propose outline for possible TAG document (finding or rec) on architectural issues relating to storage sync, linked data, etc. Due 2012-07-15 closed
<noah> ACTION: Ashok based on TPAC feedback to propose either specific TAG goal/product page on offline apps, or propose future occasional discussion w/o deliverable, or propose to drop it - Due 2012-11-27 [recorded in http://www.w3.org/2001/tag/2012/10/09-minutes.html#action10]
<noah> ACTION-700?
<trackbot> ACTION-700 -- Robin Berjon to send note to tag@ that he will send later to the AB (as himself) proposing the changes to electoral proceedings -- due 2012-11-30 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/700
RB: Overtaken by events, AB already discussing it
<noah> close ACTION-700
<trackbot> ACTION-700 Send note to tag@ that he will send later to the AB (as himself) proposing the changes to electoral proceedings closed
NM: Tactical voting in particular?
RB: Not sure
<noah> ACTION-686?
<trackbot> ACTION-686 -- Robin Berjon to try to find who is in charge of the current browser content sniffing clustermess, and see if there is a way of moving out of the quagmire -- due 2012-09-18 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/686
RB: I did that -- it is Adam Barth
LM: I heard he had withdrawn
RB: I didn't detect any way out
LM: I proposed that HTTP2 should get
us out, but they declined
... Reassign it to me, with a 3 month deadline
<noah> ACTION-686?
<trackbot> ACTION-686 -- Larry Masinter to try to find who is in charge of the current browser content sniffing clustermess, and see if there is a way of moving out of the quagmire -- due 2013-01-08 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/686
<noah> ACTION-685?
<trackbot> ACTION-685 -- Robin Berjon to create a product page proposing the Task Force on Web Security/Privileges/Trust/etc. -- due 2012-09-30 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/685
<noah> close ACTION-685
<trackbot> ACTION-685 create a product page proposing the Task Force on Web Security/Privileges/Trust/etc. closed
<noah> ACTION-713?
<trackbot> ACTION-713 -- Robin Berjon 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" -- due 2012-09-13 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/713
<noah> ACTION-715?
<trackbot> ACTION-715 -- Robin Berjon to prepare draft FPWD of some patterns for privacy in APIs, to be reviewed by TAG and published -- due 2012-09-13 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/715
NM: Anyone want to pick this up
<masinter> push to http://www.w3.org/Privacy/ or privacy interest group??
AM: This was narrowly focussed
originally, then RB added a thread to it
... As it stands it needs more material to make sense of the
addition
NM: Would you do work on it?
AM: To reduce the scope back to where it was, yes
LM: Just forward it to the Privacy Activity/Interest Group
NM: Is there a group that meets?
LM: Yes, they have telcons
AM: Privacy is this large amorphous area -- the good thing about this document originally was it had nice clear boundaries
DKA: Publish it as it stands as a note
NM: PL, can you help?
PL: Yes
NM: Please take a look and see if you can identify what we would / might publish as a Note?
LM: DKA, RB, could you draft a SotD you would be happy with?
HST: Could we answer NM's question first, please
NM: OK, PL, please include consultations with the original authors on taking this out
<noah> close ACTION-713
<trackbot> 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" closed
<noah> close ACTION-715
<trackbot> ACTION-715 prepare draft FPWD of some patterns for privacy in APIs, to be reviewed by TAG and published closed
<noah> . ACTION Peter to prepare for review a draft of a TAG Note focusing on the minimization message in the privacy finding. PL to check w/Robin and Dan first. - Due 2013-11-27
<noah> ACTION Peter to prepare for review a draft of a TAG Note focusing on the minimization message in the privacy finding. PL to check w/Robin and Dan first. - Due 2013-11-27
NM: RB, you're now clear of actions, thanks for your help
RB: I'm still happy to host in Paris in spring 2013
NM: Thanks to BCS for providing facilities
[Adjourned]