- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Sat, 30 Oct 2010 10:29:26 -0400
- To: "www-tag@w3.org" <www-tag@w3.org>
Draft minutes for all three days of the TAG's 29-21 October 2010 F2F are
now linked from the agenda at [1], and are ready for review by the TAG. I
expect we will vote on approving them on the TAG teleconference of 11
November. Plain text copies of the draft minutes are also included below.
Thank you.
Noah
[1] http://www.w3.org/2001/tag/2010/10/19-agenda
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Technical Architecture Group Teleconference
19 Oct 2010
[2]Agenda
[2] http://www.w3.org/2001/tag/2010/10/19-agenda
See also: [3]IRC log
[3] http://www.w3.org/2010/10/19-tagmem-irc
Attendees
Present
Daniel Appelquist, Tim Berners-Lee, Yves Lafon, Ashok
Malhotra, Larry Masinter, Noah Mendelsohn, T V Raman,
Jonathan Rees, Henry S. Thompson
Regrets
Chair
Noah Mendelsohn
Scribe
Henry S. Thompson, Daniel Appelquist
Contents
* [4]Topics
1. [5]Admin and agenda review
2. [6]Web Applications: Client-side State
3. [7]ISSUE-54 (TagSoupIntegration-54): HTML / XML Unification
4. [8]Generic Fragment ID Processing
5. [9]IETF Draft on MIME and the Web
6. [10]IRIEverywhere-27
* [11]Summary of Action Items
_________________________________________________________
<ht> trackbot, start meeting
<trackbot> Date: 19 October 2010
<ht> scribenick: ht
<scribe> scribe: Henry S. Thompson
<scribe> agenda: [12]http://www.w3.org/2001/tag/2010/10/19-agenda
[12] http://www.w3.org/2001/tag/2010/10/19-agenda
Admin and agenda review
NM: Recap of time as chair---coming up on two years
... Better focussed on issues coming from the community
... Some noticeable impact, but other areas where we haven't managed
to achieve much
... Obvious structural problems with affecting HTML5, but we have
made some impact there
... But on WebApps, where we said we would focus, we haven't
achieved much as I hoped we would
... Our history was for producing findings, which moved rapidly
(some of them) and ended up being well-crafted
... but that has stopped, pretty much
... Partly because we said we wouldn't do Findings, but haven't
succeeded in replacing that focus
... Some counter-examples, but mostly because we haven't been
putting the work in
... People should be putting more time in
... It's destructive for a group to say: Here's what we're going to
do
... and then not do it
... I'd like to see us figure out what we can commit to
realistically, and then do it
AM: I agree, I'm frustrated with the lack of feedback on what I have
written
NM: Meta-discussion now, or . . .
TBL: A bit, before we shift to substance
... I have put in less time over the last year, I'm hoping that's
over and I'll be able to start contributing more
... I've written about net neutrality and people being cut off from
the web
... which I'm passionate about
... Passion is important to the TAG's motivation
... Mime, URIs, yes, those are crucial
... What is it about webapps that are crucial
... I'm tasked with bringing back two TAG goals for the next six
months to Jeff Jaffe
LM: The driver for anyone is "Who wants it" -- the fear of not
meeting peoples interests is demotivating
... (to TBL) You and Jeff should drive us -- what should we be
working on?
TBL: But goals for us don't come from management
... Cracks in the architecture aren't noticed by management
NM: The webapps pblm is not that we've tried and found lack of
substance, but we haven't tried (enough)
... We need to locate, for example wrt Client-side storage, what the
main points ought to be.
LM: I need to understand the whole area before I can identify the
main points
... One role of W3C is to apply constraints/feed important
viewpoints as policies into WG activities which they might not think
or care about intrinsically
<noah> I also think we need to, not right away but early in the
process, identify the few main points we want to make, and to whom.
LM: TAG findings, and the Arch Doc(s), are how we express those
policies
... So our role is to articulate policies in a way that are
actionable
TVR: It resonates, but it takes two hands to clap
... But without respect from the WGs and the people outside the W3C
who are driving the Web there's no leverage for what we do
... and that respect has been lost
NM: Use cases are at the heart of establishing credibility
... Saying "I have a principle" is less likely to have an impact
than "I have a use case"
TBL: Getting the 'profile' attribute back is a clear example
<noah> I'll give this until 9:40, then on to storage
TVR: The successful cases are from the past, the new Web doesn't
have simple axioms or examples that you can state
... The loss of community-level standing to speak by the W3C, not so
much the TAG itself -- the TAG alone can't fix this
DKA: Wrt the W3C's role, my perspective is that in the geo-loc area,
I see the W3C playing a leadership role and being successful
... Also, when we ran the privacy workshop, we got people from
across the eco-system, and the W3C's coordination role was
recognised
... We should try to build on that kind of example
TVR: Just emphasising that TAG impact has to be based on W3C
effectiveness
<masinter> W3C effectiveness can be improved by the TAG doing a
better job
TBL: Let's decouple these -- the TAG should just do the work, and
we'll work in other arenas to improve the impact of the W3C
<noah> +1 to Tim
TBL: Agree with NM (and JJ) that we need to pick our focus, and get
to work
<Zakim> masinter, you wanted to suggest we review this later in the
meeting when we go to "next actions"
LM: When we talk about next steps, remember that the TAG being
effective also feeds into W3C effectiveness
... bringing the broader community together
... and expanding the horizons of the WGs
NM: Quality speaks for itself
... I want to look at our work and be proud of it, on the basic of
intrinsic merit
Web Applications: Client-side State
trackbot, Action-430?
<trackbot> Sorry, ht, I don't understand 'trackbot, Action-430?'.
Please refer to [13]http://www.w3.org/2005/06/tracker/irc for help
[13] http://www.w3.org/2005/06/tracker/irc
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> [14]http://www.w3.org/2001/tag/group/track/actions/430
[14] http://www.w3.org/2001/tag/group/track/actions/430
NM: Background is our commitment to build a webapps document
AM: Two documents: state and storage
NM: Oops, I missed that there were two documents
... Let's start with storage, since it's linked from the agenda
AM: Actually, I'll start with client-side state, which originated
wrt Google Maps
NM: Changes since May?
AM: Feedback from NM, LM, JAR, and that was very helpful
... In particular that not all states are reproduceable, only some,
and I'm happy to take that on board
NM: So apologies for not scheduling discussion on state
... but not much change in that area?
AM: Right
<jar_> (No news on state since early summer. The new draft is about
storage, not state. The action was about state, but Ashok wrote
about storage, and what we're about to talk about.)
AM: I would like to have a partner to actively respond to me on this
DKA: I'lll take that on
<noah> . ACTION: Ashok to write finding on client-side storage, DanA
to review
<noah> ACTION: Ashok to write finding on client-side storage, DanA
to review recorded in [15]http://www.w3.org/2010/10/19-tagmem-irc]
[15] http://www.w3.org/2010/10/19-tagmem-irc
<trackbot> Created ACTION-475 - Write finding on client-side
storage, DanA to review [on Ashok Malhotra - due 2010-10-26].
NM: Move to discussion of
[16]http://www.w3.org/2001/tag/2010/09/ClientSideStorage.html
[16] http://www.w3.org/2001/tag/2010/09/ClientSideStorage.html
<timbl> Ashok, what about evercookies?
<timbl> I see the, now
DKA: AM mentions evercookies, this is the kind of thing which we
should focus on, it got HTML5 on the front page of the NYT
... We should try to move quickly here -- can we triage this area to
get something out on this quickly?
<timbl> Note that the W3C privacy workshop and the whole new
currentlness of privacy discussion in the communiyt
<Zakim> masinter, you wanted to ask about IETF work on cookies
[17]https://datatracker.ietf.org/wg/httpstate/charter/, privacy
issues, fragment identifiers ... (items missing that I thought
[17] https://datatracker.ietf.org/wg/httpstate/charter/
LM: There is an IETF WG on HTTP state, cookies etc.
<timbl> [18]http://tools.ietf.org/wg/httpstate/
[18] http://tools.ietf.org/wg/httpstate/
<timbl>
[19]http://tools.ietf.org/wg/httpstate/draft-ietf-httpstate-cookie/
[19] http://tools.ietf.org/wg/httpstate/draft-ietf-httpstate-cookie/
YL: the goal is to produce an interoperable spec. about cookies
... both server and client
<noah> Noah needs to remind himself that ACTION-430 was about state,
as in fwd/back stack, and this is storage, which is the new
action-475
LM: What about sandboxing -- local storage is associated with a
site, and there is some model about sandboxing and tainting -- that
should be covered in more detail in this doc't
AM: Storage uses same-origin policy at the moment, subject to the
same problems
LM: What is the problem in this space -- there's more than one
approach to cross-site, how is that playing in this new area?
Exposing all that would be a good idea
AM: I borrowed stuff that JK had written about CORS and UMP, and
included that
LM: Wrt privacy, the general operation of "clear all my stored
information" was not in webarch, cookies weren't in webarch
TBL: There wasn't any local storage in WebArch
<Zakim> noah, you wanted to ask about relationship between storage
and privacy
NM: This is a finding on storage, but we move quickly to privacy
... We're failing to notice other things which are fundamental
... cookies are one, we should start with that -- here's the pure
Web, in its idealised form
... First look at cookies, SQL stores, etc. Are they antithetical to
WebArch, or can they co-exist?
... How do they relate to our existing story about WebArch -- does
this e.g. compromise our ability to give URIs to things which can be
distributed effectively?
<timbl> You have to say now that now cookies are defintely part o
fth eweb arch -- and clioent-side storage and state in general -- we
should not ask whee they are just bad. We should define the two
types of system, and give the properteis of each.
<masinter> more questions: whether this is 'storage' or 'caching'?
is it an optimization or essential? Is there a web for devices
without local storage? "public terminals", "embedded clients", ...
what is are the requirements for how much storage there is, the
possibility of malicious sites using up storage capabilities, ....?
NM: What are the tradeoffs? And only then move to privacy and
security
<Zakim> timbl, you wanted to talk about accoutability as a possible
TAG finding
TBL: Historical stories, maybe. The first stateless story has been
told. So we should recognise the existence of two systems, with
different protocols, and then look at how to use the new one
effectively
<noah> Should we walk through the document?
TBL: Privacy is really important and current, we've had all these
workshops
... Move from a world of access control to a world of accountability
... Great talk by Hal Abelson at the last MIT Privacy workshop --
the five myths of privacy
<masinter> there's a leap between 'storage' to 'privacy' which
really seems to be about sandboxing?
TBL: Proposed changing the way we think dramatically
<Zakim> masinter, you wanted to ask more questions
LM: I'm confused about the question of at what point local storage
moves beyond being a cache or an optimisation
... Do you have to have local storage to be an agent at all? Public
terminals versus privately-confined ones
<noah> I like the public terminal point that Larry is making
<noah> Of course, offline operation is very important in some cases.
LM: The stateless web had the advantage that local storage was not a
requirement
... Is it legitimate to have a client the drops all cookies?
TVR: State rides on top of the stateless HTTP protocol
... Some people say that's a hack, we should have had state in HTTP
all along
... Others say it's OK, it's good layering
<masinter> I don't think this is a moral issue or a question of
"good" or "bad" design, the question is an architectural one, of
whether there are categories
TVR: LM is right, in the process of layering we can no longer tell
if a URI is basic (clean) or basic+ (cookies needed) or
basic-super-plus (need SQL-storage)
<masinter> i would imagine an architectural requirement: web sites
that use state should still work with clients that don't have state,
although might be missing features
<noah> Need to get link to Crest
AM: Roy Fielding sent us a pointer to a website about C-REST
(Computational REST) -- a URL really points to a computation
... but it doesn't spell out state manipulation
<masinter> [20]http://www.erenkrantz.com/CREST/ ?
[20] http://www.erenkrantz.com/CREST/
AM: I thought you, TV, were talking about two or three classes, but
I don't think you can separate them
TVR: I agree you can't separate them, but the question is is that a
bug or a feature?
... If you go to CNN with a completely clean browser, it takes you
ages to actually get the news, because it requires you to answer
various questions first
... So a stateless client will always have that hassle
... The old days of getting a bag of bits, from a disk or a CGI
script, which get shown, has gone
... Now that bag of bits is run again on the client, and that can
iterate. . .
... For example the CNN video page I mentioned in my # in URL
document
<masinter> "document" <=> "application which displays document"
<jar_> (Re TV saying "you can't tell" whether the resource is
stateless, or whether there's state involved: I muse that this may
be the age-old argument of 'typeless' vs 'typeful' languages - do
types get reflected in names; are they inferrable from context; or
do you have to dive deeper to "tell" what something is like)
NM: Indeed how does the new document relate to the # in URI doc't?
<Zakim> noah, you wanted to ask about doing it right
NM: TVR said look, we had a stateless web, now this new stuff is
happening, mostly it's good, but we need to be clear what's more and
less good
... There are some things which are pretty dangerous, paralllel to
using GET to update state
... Mostly we can set out the tradeoffs, so the consequences of e.g.
using persistent local store, will be, both up and down
<masinter> What is it you have to do in order to build an
application which works reasonably with many different kinds of
devices, all with differing local storage capabilities? is that an
architectural goal?
<Zakim> masinter, you wanted to explore some kinds of findings
around state
NM: compare what we did with Cool URIs don't Change -- here's what
goes wrong when they do
LM: Interoperability -- what does it mean? Two things are
interoperable if they work identically? Or something 'works' on
small handheld, and on a big desktop screen?
... We're now looking at a range of UAs with respect to local
storage capabilities. The goal should be that the architecture makes
clear where the scalability has to come
... What are the principles that allow things to work with small or
large storage, with any cookies/no cookies/no-cross-site cookies
<Zakim> ashok, you wanted to talk about Evercookies
JAR: Parallel to the accessiblity story
AM: People are very upset about Evercookies
... Is this just one guy's hack, or has it become a Javascript hack?
NM: The guy himself did it to show how easy it was to be bad, as a
warning
<masinter> proof of concept, but each of the methods are
individually exploitable
NM: But the black hats just say "thank you" and use it
TVR: Evercookie shows how you can create a PNG file and get it back
later, which may get deleted because unrecognised. But then just use
space-char-distribution in a README, which looks quite harmless
<timbl> Yes, Larry -- there will be two parts to that, adapting diff
cient side storage -- one i ssimp;ly mapping the different sorts of
faclity (RDB, key/value etc, rdf, etc store) onto each other. The
other will be writing an ap to deal with very difering amounts of
storage.
<timbl> The latter will be very tricky and difficult to generalize.
AM: Depressing, because it looks like an arms race, parallel to the
virus situation
<timbl> (The former is till to an extent in procgress wiht various
layers)
NM: Right, so "clean local storage" is just undischargeable -- what
is covered?
TBL: I wanted to watermark email to W3C forum so I could detect
leaks. . .
... Rather than get depressed, we need to take the switch to
accountability here
AM: You can't stop people, but you can hold them accountable, is
that it?
JAR: That's the way security works in the real world, per Butler
Lampson, for instance bank security works by accountability, not
literal security
LM: "Gates, guards and guns"
JAR: Hal A's TAMI project is relevant
<masinter> that's the decomposition of security mechanisms: locked
doors that keep people out, monitors that discover when people
intrude, and punishment to hold you accountable if you intrude
TBL: [projects from Hal Abelson's "Seductive myths about privacy"
slide deck]
<jar_> [21]http://dig.csail.mit.edu/TAMI/ Transparent Accountable
Datamining Initiative
[21] http://dig.csail.mit.edu/TAMI/
<jar_> Also see [22]http://www.bitsbook.com/ book _Blown to Bits:
Life, Liberty, and Happiness after the Digital Explosion_ by Abelson
et al
[22] http://www.bitsbook.com/
<masinter> AAAA Authentication, Authorization, Accounting and
Auditing
<masinter> you can use my birth date but not my age?
AM: Yes, I have what I need
NM: Due date?
<masinter> about how to decouple storage finding from privacy
NM: Back to storage, we'll pick up on privacy tomorrow morning
<noah> [23]http://www.w3.org/2001/tag/2010/10/19-agenda.html#privacy
[23] http://www.w3.org/2001/tag/2010/10/19-agenda.html#privacy
<Zakim> DKA, you wanted to make a point on where client-side storage
fits into the "apps vs. web" debate currently playing out in the
mobile indtsyr.
<Zakim> masinter, you wanted to ask about "information" boundaries
DKA: Client-side storage hugely important in the mobile industry --
apps vs. web is a hot topic
... Received wisdom is building apps is great
... this isn't consistent with the web-as-a-platform perspective
... This means client-side storage is important to support
intermittment connectivity
TVR: Huge confusion about "what is a web application" -- web
application vs. client application is just a marketing distinction
... Lots of so-called client apps are actually web-reliant
<masinter> apps vs. web is an interesting discussion.... what is in
an 'app' that isn't in the web, besides local storage?
"installation", different security model, installation of
preferences
NM: But I can't run them on my Palm
TVR: That's just the old write-once-run-anywhere myth
... I don't want to limit web-apps to those which just run in the
browser
[general uproar]
TBL: It's an important difference
TVR: It's a continuum
TBL: "Don't build a client app, build a webapp" is my litany these
days, because you can link to it, because it _will_ run anywhere
LM: The technology used is orthogonal
TVR: My point
LM: There is a differerence between an app and something on the
there's a big security difference
<noah> There is also a difference of openness and ubiquity.
LM: An app can assume permanent storage until it's uninstalled
... An app can install a preferences dialogue
<noah> If I send a link to what Tim calls an application, it will
with high probability work wherevery you are. Not true of Android,
Flash, iPhone etc. even if heavily using Web protocols under the
cover.
TVR: Over time they are merging -- the distinction is only in your
head
TBL: One has a URI and the other doesn't
TVR: I can write an android app which jumps in and out of the
browser
<jar_> timbl: What do you mean they're merging? One has a URI and
the other doesn't
TBL: URI is itunes: ?
TVR: No, http:
<masinter> applications can use web, invoke web, etc. can they limit
web access to some sites or restrict ?
TVR: Pandora is a good example
... If the message is it's all URIs, bookmarkable, run on any
browser -- yes, that's still there
... but the app universe is much less clear
DKA: I wasn't trying to say that people shouldn't write native apps
... But the client-side storage provision is relevant in a decision
about whether to write a native app or a web app
... There are other differentiators, but client-side storage is an
important one
<masinter> i think "installation" and "preferences" are other
elements
DKA: So if we're trying to bolster web-as-platform, we need to
support client-side storage
<Zakim> timbl, you wanted to point out re client-side state the
problem of referring to a thing and a veiw of that thing, or a thing
and an app which can treat the thing, and th eissue o
TBL: There's a pattern which leads to grief: When we want the world
to be represented by one URI
... but in fact it's represented by two
... Maybe we can fix this for two, even if we can't for N
... I'm looking at a location on ???, and I want to drag it to
OpenStreetMap
<masinter> and a different security model. Perhaps applications
could be designed such that applications also produce URIs so they
can transition between app <==> webapp, if they're built on the same
technology
<jar_> "in the browser" is an implementation detail. what are the
essential aspects of the app / web app distinction from the point of
view of issues that are observable to users?
TBL: I can't as a user take "this website" and make it view "this
location"
[scribe is getting lost]
<masinter> what Tim is talking about is orthogonal -- can pieces of
application 'state' be abstracted enough that they can be shared
between applications.... vcard, map locations, etc.
TBL: Multi-dimensional reality about my interests in e.g. people --
sometimes I want them-as-located, sometimes them-as-issue-owner
... Maybe this is pushing us towards multiple-view-supporting URIs
-- separate dimensions, in other words -- what object do I have in
view, and what application do I want to apply to it?
[again, scribe lost]
<masinter> Tim wants application / web application designers to use
common abstractions for common concepts (users, locations,
telephones, ....) in a way that those abstractions can be shared
between applications
TBL: for sanity, the user shouldn't have to live in a world where
the thing and the view/facet/use are conflated into a single URI
<masinter> (to propose)
TBL: we need to untangle those things
TVR: But then we need a universal way of identifying, e.g. locations
TBL: URI of vcard or homepage can be a person-identifier
<Zakim> masinter, you wanted to talk about apps vs. web and to
propose that we define what a "web application" is, in a way that
helps clarify this
<Ashok> Thre is a project called OKKAM which will give URI to
loactions -- among other things
LM: Native apps vs. webapps -- bring different things to the table
for the developer . As NM said, starts with the installation story
... There is a natural desire to get a URI which links to an
application _in a state_ . Perfectly possible to have a native app
which generates URIs for its states, even if it's not "a web-only"
app
... That's a separate discussion from the one about what's needed
for sharing across applications -- that's harder
[NM: Short break]
Resuming
ISSUE-54 (TagSoupIntegration-54): HTML / XML Unification
NM: Detailed discussion in June at the last f2f about this
... Suggested that TBL, with help from the TAG, might try to pull an
effort together to tackle the HTML/XML convergence problem
... JJ has encouraged TBL to discuss this in public at TPAC
... TBL hesitant unless there is progress to report
TBL: This was at TVR's instigation
... There has been pushback from HTML people saying "Nothing's going
to change in HTML land, nothing's going to change in XMLland, so no
point"
... I got management support to create a task force
... If we are convinced that it has a very very crucial role to
play, let's do it
<masinter> What are the requirements for which XML was designed
which are not in HTML, and which communities need those
requirements? Extensibility, modularity, small footprint.... don't
think we can ignore those communities
TBL: But if we think there's no choice but to have two stacks, let's
not do it
TVR: The recognition of two stacks seems like one side to being a
victory to one side
... because if it goes forward, there's a real risk that [the XML]
stack will atrophy and die
<masinter> I don't think the model of "two stacks" makes sense,
describes the reality
TVR: I don't think the two-stack story has a future
... For XML to play a role on the browser-driven web, XML has to
have a place in the text/html media type
... We have to find a way to sell the value of the XML tool chain
... Because the last mile is broken, the whole XML pipeline story is
at risk
LM: XML was designed to meet some communities' requirements, neither
the communities nor the requirements have gone away
... So maybe XHTML was going wrong, so we needed a course correction
... But that doesn't mean that we can't bring those original
requirements back to the table
... Those requirements: a small, clear, consistent language with not
surprises, and modularity, extensibility, archivable
... Not shared by the main driving force of the Web, but a big
proportion of the W3C membership
... Someone argued that polyglot didn't matter, but a member (a
client) said "that's all I had" -- and they wanted not just the last
mile, but to roundtrip -- to take their website and push it _into_ a
pipeline
... We have to bring that community with us
... The ebooks /epub standards uses XHTML
<Yves> [24]http://en.wikipedia.org/wiki/EPUB
[24] http://en.wikipedia.org/wiki/EPUB
LVR: And the Daisy XML manifest
LM: The requirement for books is in part archivability, for which a
smaller more constrained language is not
... a luxury, but a real value
TBL: So we mustn't leave the polyglot community behind
HST: More than that, the all-XML community
TBL: The HTML community will say that this represents too small a
part of the Web for us to care
But it represents a much larger percentage of W3C's membership
<masinter> (a) "leading the web to its full potential" means not
looking backward but forward... what interoperabilities can we
enable?
<masinter> (b) there are too many web sites that claim they are
xhtml compliant
TVR: I don't think the numbers game matters, or trying to 'prove' to
the HTML people that they should care about XML on the Web
... What I do care about is that the XML ecosystem is preserved
... The W3C has created a very valuable collection of tools, where
XML is at the heart, and sold it to the membership
... In particular, to be able to serve the results of their
pipelines onto the Web
TBL: So protect and defend polyglot -- what are the other
requirements
... So what other things go into the terms for taskforce?
TVR: Distributed extensibility
NM: The charter of any taskforce should take a clear stand on the
HTML5 Last Call
... after which it might not change much
... So are we asking the TF to take responsibility for making HTML5
right for polyglot etc.
... _or_ is it focussed on life after HTML5
TVR: No win either way -- too late for Last Call, too soon for
post-HTML5
<masinter> task force should focus on long-term requirements, but be
encouraged to make short-term recommendations
TVR: The claim is that HTML5 is continually evolving, we can utilise
that to get improvements done
YL: The main difference is that in the XML stack is the
extensibility that is both pervasive and easily handled, whereas in
the HTML stack, largely driven by the browser implementors,
extensibility is a problem to be circumscribed and worked around
TVR: The extensibility argument has been made before many times, but
on the implementation side it has been hard about turning new tags
into new behaviour
... whereas on the HTML side the addition of new behaviour is quite
easy
... Making a raman:person element and move it around and work with
it is very important
... but so is my ability to write <div class="person>.... and get
lots of leverage wrt appearance and behaviour from that
LM: There is more to XML than extensibility. Did we lose the value
of the XML cleanup because of the pushback on extensibility?
... We've lost the conservative sender part of the duality -- for
general web use maybe that's not so important, but for
interoperability with the rest of the world it may matter a lot
... Here's a requirement (clean specification of clean sublanguage),
here's the XML ability to support that, here's what HTML doesn't
give it to us
<Zakim> timbl, you wanted to say but in fact thHTML isn't the last
mile any more, webapps is more than a mile and where a lot of th
eprocessing happens.
TBL: HTML isn't the last mile any more, but the newer architecture
involves much more computation client-side, which means its the
client that needs both XML and HTML parsers
<masinter> but the client side deals with the DOM? XML dom vs. HTML
dom independent of linearization?
TBL: So the client is (via Javascript) looking at a
tagsoup-originating DOM and XML from XMLHttpRequest
<masinter> other requirements, how to apply to HTML: XML digital
signatures, EXI....
TBL: Which pushes the question of where full HTML parser is required
into lots of obscure places
<Zakim> jar_, you wanted to (a) suggest postmortem (b) ask about
viewing html as a serialization for xml
TVR: Webkit and maybe Gecko do have tidy functionality, in that they
can serialize their DOMs
<masinter> which other XML standards & applications ... how do we
apply them to HTML?
JAR: The taskforce could look at doing a postmortem -- the current
situation is evidently unprecedented in its nature -- how did we get
here, so at least we understand how to avoid it another time
... LM mentioned that we lost the recognition of the value of
conservative to produce/liberal to accept -- how did that happen?
<Zakim> ht, you wanted to deprecate arguments based on counting
JAR: So, as a preliminary, how did this happen?
<masinter>
[25]http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5 good
perspective
[25] http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5
<Zakim> masinter, you wanted to disagree with Noah and agree with
Raman
<Zakim> ht2, you wanted to underline the vulnerability of xslt in
the browswer
<DKA> +1 to the idea of a dispassionate postmortem.
<jar_> HT: we risk losing all the advantages of XSLT
<raman> JAR's suggestion of learning from the mistakes of the past
is a good one, and I was hoping that would happen by constituting
the task force to have the right people in it. Writing the wikipedia
history article however should not be the task force's job
<masinter> -1 I think *doing* a retrospective view as a document is
not itself a good charter goal
s/advantages of XSLT/advantages of client-side XSLT in the browser/
LM: I think the post-mortem is not a good charter goal
... That's already been done, see e.g. the Tim Bray/Ian Hickson
exchange [ref?]
<masinter>
[26]http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5
[26] http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5
LM: I'd like to focus on getting back to the requirements for
re-unification
[tbl reviews the whiteboard -- photograph to come]
<masinter> signatures, EXI....
<jar_> Maybe I haven't read the right things. For me I haven't seen
an explanation of what was deeply different in this situation that
caused the classical process (professional organization, working
groups, etc.) to fail. If we don't understand this we'll just repeat
the past.
TVR: Lost the ability to look at a web page and derive an API for it
... a value of XForms which has been lost
<masinter> 'screen scraping' wins
<masinter> "extensibility" actually needs to be put into a context
where extensions aren't mandatory for 'browsers'.... e.g., using
(X)HTML in help systems which might have addtional extensions, which
aren't browser extensions. Building other applications that
integrate HTML
YL: The other direction -- Error recovery is better defined for
HTML5
NM: Suspended until 1305
<masinter> error handling should be defined for particular
applicaiton types, rather than assumed that what's appropriate for
'browser' is also appropriate for other applications
<noah> zakim +aaaa has F2FRoom
<DKA> Scribe: Dan
<DKA> ScribeNick: DKA
Generic Fragment ID Processing
issue-39?
<trackbot> ISSUE-39 -- Meaning of URIs in RDF documents -- open
<trackbot> [27]http://www.w3.org/2001/tag/group/track/issues/39
[27] http://www.w3.org/2001/tag/group/track/issues/39
Noah: we had a discussion around generic processing of fragment
identifiers in http bis.
... the specification depended on an interpretation of frag ids that
differed...
... the TAG decided that on balance the least damaging thing to do
would be to write a letter to the http working group asking for it
to be removed from bis.
<noah> [28]http://www.w3.org/2001/tag/2010/10/19-agenda.html#generic
[28] http://www.w3.org/2001/tag/2010/10/19-agenda.html#generic
Noah: links there to the proposal, etc...
Henry: In a superficial reading... insofar as there is any official
definition, there are no official definition of "ID-ness".
... bad news - xpointer spec says barenames are resolved to IDs and
defines IDs in 3 ways...
... 3 ways to find out what an element's id - one from the DTD, one
if there is an xml-schema, and one if "you just know.'
... somebody could write an x-pointer processor that "just knows"
that RDF IDs are IDs.
Norm: yes you could do that but it would be [not good.]
Henry: therefore we do not need to ask for a change in bis.
TV: Should we write this down as guidance to others who might think
there is a problem?
<Zakim> masinter`, you wanted to ask if there's a better definition
of "fragment identifiers"
<jar_> (I think Norm said something closer to 'not very smart' than
to 'not good'.)
larry: I've been thinking about fragments and what is a fragment,
especially in web applications. Documents vs. applications. Is a
document a kind of application where the application is "show me
this document"?
tim: things which are not declarative are damaging - but if you
determine state as "browser with something showing" then this
interpretation of fragments makes sense.
<ht> s/In a superficial reading/Thanks to a prode from Jonathan
Rees, investigation of the specs uncovered that on a superficial
reading/
larry: I like "speech acts" - where semantics is action - I
communicate my state to you through speech. This speech act causes
changes in state.
<noah> As chair, I'll say that I can't tell if this is a good use of
time or a rathole. Guidance would be welcome.
tim: [disagrees]
<Zakim> Norm, you wanted to say that I don't mean that by fragids
norm: for the applications I have in mind I consider fragids a way
to reach into the document and get something out - to transclude it
in an xproc pipeline, to count the number of characters, - not
necessarily to display or change anything.
... i think this is contradictory to what larry said.
larry: I don't think so - if you want to communicate a route from
one mapping application to another it could be via a fragment
identifer.
<Zakim> noah, you wanted to say that we may need health warnings on
registration of new +xml media types
norm: I think of it as a stake in the ground that I can navigate to.
tim: it's important not to generalize too much about frag ids it's
valuable to for RDF to use frag ids in a certain way - languages in
the future might choose to use them in a different way.
<Norm> +1
noah: I don't recall a health warning in the draft that those who
register new media types need to be careful (about frag IDs).
... it seems to me that it might be worth encouraging the editors to
say "in the cases where the frag IDs supported by your media type
overlap syntacticly with those provided by the generic then...
[something]"
tim: how do you grandfather conflict in RDF?
Henry: there is no conflict with RDF.
JAR: Do the specs say that when the frag ID when it's defined by XML
ID has a certain meaning or do the specs say "when you see a frag id
then it's defined by xml id"? There is a difference.
<jar_>
[29]http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-x
ml-04.html section 5
[29]
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html
[disagreemnent on whether this conflicts with RDF]
JAR: It conflicts with RDF.
Harry: if your arbitrary foo+xml defines frag ids whose frag ids
syntax overlaps with xml id then there's a conflict.
<jar_> "Conformant applications MUST interpret such fragment
identifiers as designating that part of the retrieved representation
specified by [XPointerFramework]"
tim: either you want that behavior or you don't want that...
harry: I want to know what conferment applications means - generic?
<jar_> "such fragment identifiers" means what?
<ht> and "conformant application" means what?
<ht> s/harry/henry/
Noah: The way to distinguish generic - did you as author of the code
follow a path informed by the rdf media type registration? [on
whether tabulator is generic or specific]
<jar_> ... for RDF, the application CAN'T interpret it that way,
because the fragid isn't an xml id...
tim: no there is no code that looks up how to process things...
s/harry/henry/
tim: any attempt to look at that RDF document with xpointer
processing is broken...
... a test case would be a document that has both kinds of IDs...
jar: that would be a bad file - it would cause the id to be
interpreted in different ways depending on which spec you are
following...
noah: simple case: somebody decides : we like to use XML ids to
manage our XML. Some of it happens to be RDF. The people who
understand RDF....
[heated discussion]
jar: [writes example on whiteboard]
rdf: ID = "a" -> Person ; xml:id="b"
jar: doesn't occur in nature because people don't put xml:ids in RDF
docments.
noah: Neither is there a spec ruling that out.
<noah> The example rdf:id="a" -> person rdf:id="b" -> element is NOT
a problem
<noah> The example rdf:id="a" -> person rdf:id="a" -> element IS a
problem
<Norm> I'm not sure it's *possible* to define things such that
conflicts are impossible, and in practice I don't think they ever
happen, so...I'm not sure if I feel like I should worry.
<noah> That's what Jonathan put on the board
tim: fundamental principle: the semantics of a URI is context-free.
<noah> (Jonathan confirms I got that right).
henry: you know that that's false - you can't tell what the
semantics are until you know the media type of what the browser
sends you.
tim: no.
jar: each representation delivers constraints...
tim: if I say foo#a is interesting...
henry: you can't say if that's coherent or not until you retrieve
that URI...
... [restating] what it means to be a generic processor is: you're
only interested in constraints that come from a certain class of
media types. "I am going to view these documents through a set of
lenses consistent with only the 3023bis semantics..."
<jar_> a generic processor is only getting a subset of the whole
theory of the fragid. that's fine
noah: on one hand you're talking about a generic piece of code -
written as a generic processor - then a second piece of code written
as an RDF processor sees the same code and interprets it
differently. [Is that OK?]
... if this exists in principle - I was worried about what I just
described... that's why I think a health warning needs to be in
[3023bis].
<noah> PROPOSED (by Noah) Registrations for media types of the form
application/XXX+xml SHOULD NOT define semantics for fragments that
would resolve in a manner that is inconsistent with the generic
rules
henry: we're saying - documents like this shouldn't be written...
tim: which document - I've got two but I'm going to send you one of
them based on my interpretation of your request...
henry: If it's an rdf processor and you give it the second document
[on the board] it will have nothing to show you....
noah: 3023 does not currently give it that semantic...
<noahm> Is it clear that we're to make mistakes?
yves: how to process the fragments, based only on the mime type you
get back. The purpose of 3023 bis is to say - if you don't know the
semantic of the mimetype ...
... it's not a big issue. If you don't know RDF then you don't know
RDF...
tim: it's an issue because if you get something else displayed...
yves: it's like displaying an image as text - you get some random
bytes...
<jar_> tabulator can translate xml:id="a" into a set of RDF
statements (and would be 'authorized' to do so by 3023bis)
<Yves> my point is that using the defaulted behaviour, you know that
you don't know the meaning of the fragment
<ht> only if that processor was doing reflection on a bit of XML as
an object in the RDF, I think
martin: I could imagine a piece of software that says "rdf / xml -
ok I can do something with this as XML because I know XML and I know
how to do something with RDF - so then I see #a so in one case I
find an RDF ID so I go to the rdf processor or I could find an XML
ID and go into XML processing... There could be inconsistent
[behaviour]. I think a health warning could be a good thing.
noah: [presents a proposal]
Henry: [disagrees with noah's proposal]
<noah> Which was:
<noah> PROPOSED (by Noah) Registrations for media types of the form
application/XXX+xml SHOULD NOT define semantics for fragments that
would resolve in a manner that is inconsistent with the generic
rules
<noah> I clarified that "consistent" means, roughly: "if it resolves
in a given document per the generic rules, then it resolves to the
same thing per the specific media-type registration" (note that it's
OK for it to resolve per the specific rules and fail to resolve per
the generic)
Henry: 6 or 8 years ago we were talking about scuds - schema
components - how do you point to schema compontents? People said
obvious thing would be to use a #name - that's a problem. so we put
XML ids in the schema document - and you can use #foo to refer to
them. It would work but it would be messy and confusing.
... the fact that we were labelling an element but naming and
underlying component seemed sensible...
... [similarly] I don't have a problem with inconsistency across
levels.
<jar_> ht: The fragid names one thing, but identifies another. No
one was bothered by the pun.
Noah: I'm talking about a health warning for the range of potential
future media types that people might register.
<Norm> I think I agree. Inconsistency across levels doesn't bother
me. I think.
Henry: I'm not happy with [Noah's proposal] because I don't want to
rule out the "pun."
<ht> scribenick: ht
<Ashok> HT: I withdraw ... not convincing people
NM: Objections to my proposal?
LM: Yes
HST: Not happy unless 'inconsistent' can be spelled out
<noah> I tried with:
<noah> I clarified that "consistent" means, roughly: "if it resolves
in a given document per the generic rules, then it resolves to the
same thing per the specific media-type registration" (note that it's
OK for it to resolve per the specific rules and fail to resolve per
the generic)
<noah> That help at all, Henry?
JAR: I guess we could try to converge on allowing the pun, but I
think that would be inconsistent with past pronouncements
... I would prefer something with a MUST
... and I don't think any grandfathering would be needed
<timbl> logger, popinter?
<noah> I think SHOULD is appropriate given the precedent of conneg;
that's another case in which the same fragid can resolve
"inconsistently". that's a SHOULD NOT.
JAR: I want to say something that rules out overriding XPointer
<noah> So, if it's a SHOULD NOT there, why be stronger here?
<DKA> Scribe: Dan
<DKA> ScribeNick: DKA
<ht> JAR: "If XPointner defines the fragid to designate something
successfully, it cannot be overriden"
<ht> s/XPointner/XPointer/
<ht> TBL: I will disagree with anything that isn't crisp
<noah> I can certainly live with MUST NOT if you can get a
formulation everyone likes.
jar: xpointer does define the frag IDs...
<Norm> I'm with Larry, this boils down to policy at the spec level
and MUST seems too restrictive
<noah> Can we wordsmith specific text that might garner consensus>
<noah> Henry, please type what people were agreeing with..
jar: yes I agree with [what henry wrote]
<noah> My IRC missed it.
<ht> JAR: xml:id means an element, no problem -- that's consistent
with RDF
<Zakim> ht, you wanted to ask Noah what he thinks of the SCD example
henry: if there is an anchor that xpointer can identify then that's
what it means...
<ht> scribenick: DKA
<noah> The chair is trying to get to the queue...with limited
success.
jar: if you want to be faithful in RDF then you need to get all of
the alternative representations...
henry: the clearest example: in an xml literal you can use xml ID...
<ht> s/xml ID/xml:id/
norm: As long as the solution does not change 3023bis in ways that I
previously said I objected to then I could live with almost
anything...
<jar_> +1 Henry's wording above "If XPointer defined the fragid to
designate ..." (the only other options are punning and
grandfathering rdfxml)
<Norm> +1 to Larry on that point.
larry: I'm skeptical around must requirements in documents that
establish processes... Mime type registrations are not mandatory...
we have a lot of unregistered mime types. The more barriers you add,
the more impediments you put to registering things in the first
place...
noah: the MUST is against registering a media type...
tim: must is used in a protocol definition - if you obey the musts
then you obey the protocol and you get a specific effect.
<timbl> Larry, MUST is used in the sennse of "if you do the things
in MUST then you get the benefits o fthe protocol.
larry: let's avoid the imperative text and just say what the
consequences are...
<Zakim> masinter`, you wanted to note that registration isn't
mandatory, and more constraints on registration the more likely it
is people just won't bother registering
<Zakim> duerst, you wanted to say (to Tim) that there is no
requirement on RDF processors to interpret any and all graph
information in a rdf+xml document. As an example, an RDF processor
martin: answering to Tim - he's worried that every RDF processor
would need to do xpointer processing [if following Jonathan's
proposal]. No...
tim: when the publisher of the document has asserted a set of
triplets - the intent of the document is the triples and only the
triples.
martin: if someone put in an XML ID...
<noah> I think the "consequence" is: "if you register a media type
that provides for resolutions that are not consistent (in the sense
above), then generic processors WILL resolve identifiers per the XML
rules"
tim: the XML ID has no significance...
martin: if you open in in emacs xml mode...
tim: then you are violating the architecture of the Web
... it's clear that when someone clicks on a link...
noah: with the plus syntax in 3023bis - it is called out
specially...
tim: the +xml is to say to processors e.g. "you might run this
through SAX..."
<Zakim> noah, you wanted to talk about should vs. must
<timbl> I challenge people to find any application which actually
looks at the "+xml" in the media type -- so we can see what it does.
<Zakim> jar_, you wanted to answer Larry re "must" ... this is easy
to fix... just say that certain fragids are defined according to
xpointer
noah: I defended SHOULD - I find the fact that con-neg already
produces inconsistent results ...
<noah> NM: What I said was, I think SHOULD would be consistent with
the precedent of conneg, but I can live with either SHOULD or MUST
if either generates consensus.
jar: it's [$1\47] is already using MUST language - you can just make
a statement that the frag IDs in this document are defined in the
following way...
<noah> That's a MUST about what conforming processors do; now we're
considering a SHOULD vs. MUST on media type registrations.
jar: it sounds like we really are talking about three different
proposals. tim was suggesting that rdf+xml should be
grandfathered...
... that [should] satisfy norm.
... henry's proposal won't break anything either.
... we have 3 different positions...
larry: I have a proposal.
<Zakim> duerst, you wanted to say that the TAG should wrap up and
make sure work on 3023 starts again (currently, the official draft,
<Zakim> ht, you wanted to ask about the XSLT case
henry: on what Tim said - none of the options we discussed mean you
need to change tabulator... suppose xslt stylesheets were served
with a +xml media type - the obligation to interpret frag ids
generically applies to xslt processing, does this mean that every
xslt processor writer needs to impleent xpointer? No unless they
want to interpret xml ids...
tim: an xslt processor runs xslt - if I have foo.xslt and I serve it
as +xml - and I make a link to foo.xslt#bar and the xslt spec says
nothing about semantics - your browser is obliged to show you
#bar...
henry: it's not wrong for it to show me the rdf xml if there wasn't
a hash...
... so why shouldn't it show you the piece of the document marked by
the frag id if there is a hash?
tim: it should say "invalid xpointer"...
<noah> I think it's (Xpointer doesn't resolve, it's not
syntactically invalid)
<Zakim> masinter`, you wanted to propose my alternative, "just
describe the consequences"
[discussion goes on with xml IDs in RDF, XML documents]
larry: this is my proposal.
noah: [calls for all proposals]
<ht> JAR said "If XPointer defines the fragid to designate something
successfully, it cannot be overriden"
<noah> 1 = Larry's) NOTE: Some generic XML applications may treat
documents labeled as application/XXX+xml using generic processing of
fragment identifiers; this will result in inconsistent handling of
fragments with those that have specific identification.
<jar_> If XPointer defines the fragid to be something (as opposed to
error), that's what the fragid designates. Other fragids can be
defined by +xml registrations.
<timbl> ^2
<timbl> 2 suffers from the problem that all RDF processors have to
have a xpointer stage added
<Yves> well generic processing use only a fixed subset of possible
xpointer schemes
<noah> 3 Noah = Registrations for media types of the form
application/XXX+xml SHOULD NOT define semantics for any fragment
that would cause it to resolve, in a particular document, to
something other than the result of the generic processing.
<noah> If that becomes a MUST, rdf+xml must be grandfathered.
<jar_> inconsistency in the specs, larry.
<duerst> maybe it's the java convention?
<timbl> 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.
<jar_> 4. (jar's reading of tim's mind) rdf+xml is exempt from the
terms of 3023. +xml only has the 3023 meaning if it is not rdf+xml.
("grandfathering")
<timbl> logger, pointer?
<timbl> Tracker, can we make a vote?
noah: this is not a binding tag vote - it is a fact-finding
exercise. Please type into IRC which you like best, if there any you
can't live with...
<duerst> any is okay, I'd prefer 2, but not strongly; I disagree
with Tim that RDF processors would need additional implementation
work.
<jar_> I'm OK with 1, 2, 4. 3 is a bit soft. some preference for 1.
<ht> I like 2 best. I can live with 1, 3 (with s/resolve/identify/),
4 and 4'
<noah> Like: 3 and 2, probably in that order. OK with: Timbls "When
the mime type is *+xml, then..." Not happy with 1 or <jar_> 4
<timbl> live with 1, can't live with 2, No to 3, Like 4
<Ashok> I can live with 1
<Yves> I like 1 best. Can live with all the others.
<jar_> s/some preference for 1/some preference for 2/
1, 3, 4 are OK.
(in order)
<jar_> (thinking aloud) 4 is tidy compared to 1, it says no more
weird uses of fragids in other +xml types... might be cleaner
guidance
<jar_> s/to 1/to 2/
noah: we need someone to take an action to write a note "the TAG has
reconsidered its previous action - a. we understand the need for
generic XML processing so we are happy to have the text not removed
b. we are [worried] about registration of future media types and
recommend a warning be written along these lines "..."
... only other alternative - if nobody drafts it - I will take an
action to say that the TAG removes its concerns ...
action rees to draft a short note to 3023bis editors reflecting the
discussion / consensus...
<trackbot> Created ACTION-476 - Draft a short note to 3023bis
editors reflecting the discussion / consensus... [on Jonathan Rees -
due 2010-10-26].
martin: somebody should tell somebody to fix that rdf xml dtd that
got people confused...
jar: we could put a comment at the top...
... I could write a sentence and send it to Yves...
IETF Draft on MIME and the Web
[30]http://tools.ietf.org/id/draft-masinter-mime-web-info-00.html
[30] http://tools.ietf.org/id/draft-masinter-mime-web-info-00.html
Larry: I got some feedback that it wasn't about mime - or just about
mime. It's not about all of mime.
... I've tried to give some context of web architecture - thinking
back to how MIME was added to email.
... there were lots of document formats. How is it when you
communicate from one to the other you tell someone what language it
is.
... when you speak in natural language, you "sniff" - you sniff that
I am speaking english. But computer languages you usually designate.
... so MIME was designed as a labelling system - for email.
... originally, HTTP didn't have content types - it only had html.
Unless you wanted to send plain text.
... a popular system at the time was Gopher - it has code fields...
... single character mime type...
... and we had discussion about shouldn't we use the same labelling
for file types.
<abarth> hi
Larry: I'll make a pass thru the document and go back and talk about
what needs to happen - I'd rather this be a TAG document than a
personal one.
... section 2- history - about how mime added to the web the notion
that it didn't predefine what kind of documents you could have...
allowed adding image types, etc...
... original "distributed extensibility" - the file type was
independent of the URL was independent of the protocol.
... same as for email.
... some problems - ways in which email delivery isn't the same as
web delivery. In the Web there is a request and the response is
interpreted in the context of the request.
... section 3.3 deserves some expansion...
... section 4 - other notes - [e.g. charsets]
... 4.3 polyglot documents - a single content type which can be
delivered as more than one label. The same content delivered in
different labels could mean the same thing but could also mean
different things depending on the labels...
abarth: Another word for polyglot that gets used a lot is
"chameleon" .
larry: [moving on] what is the purpose of the mine registry? [to
enable interoperability around well-known media types] It's the out
of band way in which messages are self-describing.
... but - languages evolve. I would like to distill the [previous]
versioning discussion into something in this document...
... the registry points to a document, a specification, but also
about what is being spoken "on the street."
... [lack of version numbering an issue]
... content negotiation and the use of mime types... web
architecture says how frag IDs are supposed to be interpreted but
MIME type registration doesn't say anything about fragment
identifiers...
... still some problems with how we're executing on MIME and
belonging in this discussion is [information on] sniffing.
... section 6 is to lay out some specific recommendations - lay out
the requirements for a charter for a working group to actually make
the changes to the mime registry. It's a matter of staging so we
agree on the problem space.
noah: it's not clear to me how normatively media types registrations
apply to file systems unless the file system chooses to adopt it.
larry: in the web, people still pass around ftp: urls - I'm trying
to lay out some things that need to be in the registry....
... [back to the document] ...
... 6.2 - sniffing -
... first part of the document lays out the history and some of the
problems; then goes to recommendations...
tv: I would like to see - all the rules we would like to see for
MIME on the web should be applied consistently to mail attachments.
It's important for example for when you are displaying mail in a web
browser.
larry: part of the reason for pursuing this as an IETF document is
to give it a position where the mail client implementers are
participating in the discussion as well.
adam: imagine someone invented a new image format called webP and
they wanted to use this on the web - what would the lifecycle look
like?
larry: you register the type, you deploy viewers, ....
adam: with regard to sniffing, do you think sniffers should sniff
for the new mimetype or should we forbid sniffing of this new image
type?
... trying to see how things will evolve beyond our messy world.
larry: in a managed world, you don't guess that things are
mislabeled unless in cases where they are frequently mislabeled.
tim: should we put energy into making the Web work better compared
to http?
larry: it should also apply to a USB stick with web files on it...
tim: the http system does have defined types for files - as opposed
to other systems like the filesystem - should we spend our energy
trying to encourage people to use http or how to use sniffing when
everything fails?
larry: don't see it as an eirher-or.
... we need to be clear about the current state of play and what
needs to get fixed, but it's impossible to imaging a world where you
never need to sniff.
noah: you're talking about what media type registration needs to say
but FTP never refers to the media type...
... there are jpegs delivered through http with an explicit media
type...
... if FTP doesn't use media types then it shouldn't talk about the
media type registration
[imagine a spherical cow]
noah: I imagine a world - a file format specification for jpeg -
does not refer to the media type registration. Most file systems
will refer to that - not to the media type registration.
... I imagine a media type as a second document. In your messy
situation there are certain user agents who say "i cheat."
larry: the registry is more than just a label.
noah: it [partially] duplicates the file format spec...
larry: the constituencies that need to know this information:
... there are tool chains...
... the middleware of the web delivery chain - people who run web
servers, people who run photo sites, virus scanners, content
distribution sites...
... as consumers of file types, I want to put the information that
the middleware people might need to know ...
adam: the image resizer needs to know when the request is flying by
needs to know it's jpeg...
... the jpeg case - you have a browser that's going to take jpegs
and pngs ... suppose there is a response labelled as txt and the
image resizer doesn't resize it - and it arrives at the browser not
resized...
noah: there are parts of the architecture where it's a clean
approach. We need to proceed carefully. The system will be more
robust - be more "follow your nose" [if it follows the rules...]
larry: this document - does not propose any changes to how
implementations work today. the goal is to move the place in where
what we are implementing today is described in a way in which the
changes we are making as the web evolves are [easier / more
sensible]
adam: [is the way you guess going to change in the future? -
paraphrased by henry]
<jar_> larry: I think there will always be workflows in which you'll
have to guess the type
larry: there will be new filetypes.
<ht> but will there be new filetypes which need to be the result of
sniffing
larry: I certainly would like to avoid having content that is
labelled with syntactically correct labels being interpreted as
something else without strong evidence that mislabelling is
[prevalent].
... if receivers refuse to sniff then senders will not mislabel.
... it has been the case that if you get market leaders to not sniff
new types then people will test their conent.
adam: this is the prisoner's dilemma - think about video example.
larry: I think this dilemma belongs in section 3. Establishing what
the problem is -
... what is the mechanism by which sniffing can be avoided?
adam: think about ie9 - they are making progress...
larry: precedent - I remember when we tried to introduce the host
header into http - it was going to be required to send the host
header, nobody wanted to do it, but apache got configured to pop up
an error when you didn't send a host header, and within 4 months the
browsers all changed...
... the people who wanted to host header were the big hosting
companies... there was a financial incentive [to deploying this
version of apache].
#webhistory
larry: if we can [do something similar we can encourage people] to
fix their implementaitons.
adam: I tried to figure this out from a game theory perspective...
larry: some people - e.g. the firewall vendors - are going to sniff.
adam: they are going to sniff in the same way the browsers are going
to sniff...
larry: every piece of content is possibly a level upgrade ...
adam: there is the file in linux with all the magic numbers for file
types... We looked at how is this different from the browsers and
could construct attacks based on this...
noah: you could imagine a firewall that silently blocks stuff -
there can be false positives on sniffing... It's good to realize
that.
adam: sniffing could be perfectly predictable - if everyone agrees
on what algorithm to use.
tim: it could be predictable but it's not always going to be right.
larry: there is no logical path to come from where we are to where
everyone agrees on sniffing.
... the email vendors aren't following along - the firewall vendors
aren't following along.
noah: you're also punching a hole in the space of data you can deal
with...
<noah> [31]http://webarch.noahdemo.com/Metadata/
[31] http://webarch.noahdemo.com/Metadata/
noah: [points to example]
... imagine this is a bug database - and they put it there to say
"this is not well-formed xml" - can't serve this as text/plain
larry: I'd like to cut off discussion on whether or not sniffing is
good.
... the goal here is not to endorse practices but to acknowledge
them, show a path forward, and show how it can evolve.
ashok: I heard - in this document add a standard sniffing
algorithm...
larry: I want to have enough information in the registry so that
they sniffing algorithm could point to it.
adam: Today, I am convinced that new content types will also end up
with sniffing... [so we will need it...]
noah: why do the webP people want it?
adam: webP want to replace jpeg - they say "jpeg gets to sniff, why
not us?"
noah: my ISP that if I put a jpg file they will send it as jpeg but
if I put a new thing they will send it as octet stream or
something...
larry: we need to tell this story.
noah: it would be nice if my ISP could get at the registry - thus
closing the loop-hole.
larry: [back to the document] one of the things we haven't touched
on - practices in the community we want to ask people to stop...
adam: you're proposing that the signatures be part of the MIME
registry?
larry: some of them are in the mime registry already...
adam: if you have a separate registry - you might end up with fewer
signatures and therefore less sniffing.
larry: I want them all the be filled out - I want the servers to do
the sniffing so that the channel to the client is more reliable. If
there is unlabelled content then you should do the sniffing closer
the source.
adam: the folks who maintain the mime registry - do they understand
the issues?
larry: they are us
... we have to establish the procedures.
adam: the one benefit of putting it in a standards track document is
that these document go through a review process...
henry: after we launched the xpointer scheme registry - the only
review was a mailing list - that generated real reviews...
noah: does that feel good enough for infrastructure of this
criticality?
henry: the media type registration list does get watched.
adam: i think it's a generally reasonable direction.
larry: I want to identify clearly what the problems are.
adam: i am worried about the incentives of various parties.
<noah>
[32]http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.htm
l
[32] http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html
IRIEverywhere-27
adam: at what level of detail should you describe - if you have a
hyperlink in an html document how do you resolve it - the IRI spec
is not accurate to what browsers do - what should we do?
larry: there is a proposed spec that is more accurate. we are trying
to fix it.
... martin is not completely happy with all the changes...
... roy was skeptical of if it was possible to capture all the ways
applications can process strings and turn them into IRIs
... document that is the subject of the wg - 2 documents - update to
the IRI spec, has an appendix (7.2) the preprocessing steps to take
a web address and turn it into an IRI...
noah: adam has identified some problems, larry said we're making it
better... is there a way forward?
adam: there are several communities ... using URIs and IRIs ... if
you have to write one document that pleases every community ... the
plan is to write two documents ... we will try to reconcile these
documents is there are problems. My document will be written from
scratch.
larry: working group chairs are interested in having you [adam]
write a draft that they could incorporate as a working group work
item...
[discussion on working with ieft]
<noah> HT: The history of the LEIRI note was that someone working on
an XML specification found themselves yet again preparing to copy
the same transformation rules, because there was no referenceable
common text to which one could refer.
<noah> HT: The strings start out between quotes in XML text
documents, and need to wind up as RequestURIs in HTTP.
<noah> HT: We thought, for awhile, that it would be in 3987bis, but
that stalled for other reasons.
<noah> HT: We then got agreement from Martin and (Michel?) to
include it in IRIbis? so that we could refer to it. I'd be very
sorry to lose that.
<noah> AB: The section in question is an order of magnitude too
small.
<noah> HT: I want to keep our concern "available". We still want
that common reference point.
<noah> AB: Not 100% familiar with constraints. Not sure whether
they're the same as HTML?
<noah> HT: I haven't looked at 7.1 recently.
<noah> LM: Let me make sure it's really 7.1 we care about.
<noah> AB: Consider an example of the query string. There's some
character not representable in the character set. Some choices for
how to represent it. In HTML we...
<noah> HT: I know the story.
<noah> AB: It's % escaped...
<noah> HT: Using the document encoding
<noah> HT: Pretty sure XML wants UTF-8, would have to check.
<noah> HT: Fairly sure it's independent of the character encoding of
the XML document.
<noah> AB: HTML browsers are simple.
<masinter>
[33]http://tools.ietf.org/html/draft-ietf-iri-3987bis-01#section-7.1
[33] http://tools.ietf.org/html/draft-ietf-iri-3987bis-01#section-7.1
<noah> AB: Example [34]http:///example.com (noting the intentional
triple /)
[34] http:///example.com
<noah> AB: Some specifications give parses like // being the
hostname and /example.com/ being the path.
<noah> LM: File URIs...
<noah> AB: Don't want to talk about them
<noah> LM: But we need a common parsing rule, independent of scheme.
<noah> AB: There are 4 sets of parsing rules, depending on scheme
Summary of Action Items
[NEW] ACTION: Ashok to write finding on client-side storage, DanA to
review recorded in [35]http://www.w3.org/2010/10/19-tagmem-irc]
[35] http://www.w3.org/2010/10/19-tagmem-irc
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [36]scribe.perl version 1.135
([37]CVS log)
$Date: 2010/10/29 17:42:06 $
[36] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[37] http://dev.w3.org/cvsweb/2002/scribe/
================================
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Technical Architecture Group Teleconference
20 Oct 2010
[2]Agenda
[2] http://www.w3.org/2001/tag/2010/10/19-agenda
See also: [3]IRC log
[3] http://www.w3.org/2010/10/20-tagmem-irc
Attendees
Present
Ashok Malhotra, Dan Appelquist, Larry Masinter, T.V. Raman
(Rohit Khare), Tim Berners-Lee, Yves Lafon, Jonathan Rees,
Henry Thompson, Noah Mendelsohn, John Kemp
Regrets
None recorded
Chair
Noah Mendelsohn
Scribe
John Kemp, Larry Masinter
Contents
* [4]Topics
1. [5]Domain Name Persistence
2. [6]Web Apps Architecture
3. [7]Privacy
* [8]Summary of Action Items
_________________________________________________________
<trackbot> Date: 20 October 2010
<johnk> Scribe: John Kemp
<johnk> ScribeNick: johnk
<jar_>
[9]http://www.w3.org/2001/tag/2010/10/persistent-reference-slides.pd
f
[9] http://www.w3.org/2001/tag/2010/10/persistent-reference-slides.pdf
Domain Name Persistence
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 -
[10]http://www.w3.org/2001/tag/2010/10/persistent-reference-slides.p
df
[10] http://www.w3.org/2001/tag/2010/10/persistent-reference-slides.pdf
<raman> .
JAR: summarizing my memo from last week -
[11]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
[11] http://www.w3.org/2001/tag/doc/persistent-reference/
<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_> [12]http://www.w3.org/Consortium/Persistence.html
[12] 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> [13]http://www.w3.org/2001/tag/group/track/actions/444
[13] 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> [14]http://www.w3.org/2001/tag/group/track/issues/50
[14] 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
[15]http://www.w3.org/2010/10/20-tagmem-irc]
[15] 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:
[16]http://www.w3.org/2001/tag/2010/10/PersistenceTreeWhiteBoard.jpg
[16] 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
[17]http://www.w3.org/2010/10/20-tagmem-irc]
[17] 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
Web Apps Architecture
[18]http://www.w3.org/2001/tag/2010/10/19-agenda#WebApps
[18] 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
Privacy
NM: workshop coming up in December on this topic:
[19]http://www.iab.org/about/workshops/privacy/
[19] http://www.iab.org/about/workshops/privacy/
<noah> ACTION: Noah to Ping Thomas again on Dec. Privacy workshop
recorded in [20]http://www.w3.org/2010/10/20-tagmem-irc]
[20] 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> [21]http://www.w3.org/2001/tag/group/track/actions/460
[21] 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:
[22]http://www.w3.org/2010/policy-ws/agenda.html
[22] http://www.w3.org/2010/policy-ws/agenda.html
<DKA> Nick Doty's paper:
[23]http://www.w3.org/2010/policy-ws/papers/03-Doty-Wilde-Berkeley.p
df
[23] 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:
[24]http://lists.w3.org/Archives/Public/www-tag/2010Aug/0030.html)
[24] 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 -
[25]http://samy.pl/evercookie/
[25] 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> [26]http://www.ietf.org/proceedings/77/slides/plenaryt-5.pdf
[26] 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?
[27]http://blog.mozilla.com/security/2010/03/31/plugging-the-css-his
tory-leak/
[27]
http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/
NM: how can you possibly filter *everything*?
<tvraman-prime> DKA cited: [28]https://panopticlick.eff.org/
[28] https://panopticlick.eff.org/
<ht> The tool I'm referring to is [29]http://sandboxie.com/
[29] 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 :
[30]http://www.nytimes.com/2010/10/11/business/media/11privacy.html
[30] 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> [31]http://www.w3.org/2001/tag/2010/10/19-agenda.html
[31] 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>
[32]http://lists.w3.org/Archives/Public/www-tag/2010Oct/0061.html
[32] http://lists.w3.org/Archives/Public/www-tag/2010Oct/0061.html
AM: I'd propose
[33]http://lists.w3.org/Archives/Public/www-tag/2010Oct/0064.html as
an introduciton to the WebApps chapter of WebArch
[33] http://lists.w3.org/Archives/Public/www-tag/2010Oct/0064.html
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> [34]http://www.w3.org/2001/tag/group/track/actions/430
[34] 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> [35]http://www.w3.org/2001/tag/group/track/actions/430
[35] 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> [36]http://www.w3.org/2001/tag/group/track/actions/434
[36] http://www.w3.org/2001/tag/group/track/actions/434
<DKA>
[37]http://lists.w3.org/Archives/Public/www-tag/2010Oct/0068.html
[37] 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
[38]http://www.amazon.com/Scrolling-Forward-Making-Documents-Digital
/dp/1559705531
[38]
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> [39]http://www.w3.org/2001/tag/2010/sum07.html#html
[39] http://www.w3.org/2001/tag/2010/sum07.html#html
<noah> That's the TAG's July report on HTML 5
progress/impact:[40]http://www.w3.org/2001/tag/2010/sum07.html#html
[40] 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 [41]http://www.w3.org/2010/10/20-tagmem-irc]
[41] 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> [42]http://www.w3.org/2001/tag/group/track/actions/430
[42] 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
[43]http://www.w3.org/2010/10/20-tagmem-irc]
[43] 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
[44]http://www.w3.org/2010/10/20-tagmem-irc]
[44] 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> [45]http://jeffersonsmoose.org/
[45] http://jeffersonsmoose.org/
<noah> RESOLUTION: Minutes of 7 October 2010 are approved
<timbl> jar, [46]http://www.w3.org/2010/roadmap/tag-goals.svg
[46] http://www.w3.org/2010/roadmap/tag-goals.svg
<noah> ACTION: Noah to inform TAG of TPAC meeting schedule [recorded
in [47]http://www.w3.org/2010/10/20-tagmem-irc]
[47] 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
[48]http://www.w3.org/2010/10/20-tagmem-irc]
[48] 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 [49]http://www.w3.org/2010/10/20-tagmem-irc]
[49] 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_> [50]https://www.csail.mit.edu/mrbs/
[50] https://www.csail.mit.edu/mrbs/
<jar_> [51]http://lists.w3.org/Archives/Member/tag/2010Oct/0059.html
[51] 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> [52]http://www.w3.org/2010/10/19-tagmem-irc.html#T21-42-47
[52] 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> [53]http://www.w3.org/2001/tag/group/track/actions/476
[53] 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> [54]http://www.w3.org/2001/tag/group/track/actions/466
[54] 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
[55]http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.htm
l on 26 August (followup to 24 June and 12 August discussion) -- due
2010-10-12 -- PENDINGREVIEW
[55] http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html
<trackbot> [56]http://www.w3.org/2001/tag/group/track/actions/448
[56] http://www.w3.org/2001/tag/group/track/actions/448
<noah> close ACTION-448
<trackbot> ACTION-448 Schedule discussion of
[57]http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.htm
l on 26 August (followup to 24 June and 12 August discussion) closed
[57] http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html
<timbl> [58]http://www.w3.org/2010/roadmap/tag-goals.svg
[58] 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
[59]http://www.w3.org/2010/10/20-tagmem-irc]
[59] 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].
Summary of Action Items
[NEW] ACTION: Appelquist to draft overview document framing Web
applications as opposed to traditional Web of documents Due:
2010-11-01 recorded in [60]http://www.w3.org/2010/10/20-tagmem-irc]
[NEW] ACTION: Ashok to update client-side state document with help
from Raman Due: 2010-11-30 [recorded in
[61]http://www.w3.org/2010/10/20-tagmem-irc]
[NEW] ACTION: Ashok to write a draft on client-side storage with
help from DanA Due: 2010-11-30 [recorded in
[62]http://www.w3.org/2010/10/20-tagmem-irc]
[NEW] ACTION: Henry to organize meeting on persistence of domains
due: 2010-02-28 [recorded in
[63]http://www.w3.org/2010/10/20-tagmem-irc]
[NEW] 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
[64]http://www.w3.org/2010/10/20-tagmem-irc]
[NEW] ACTION: Noah to alert chairs, ac-forum, www-tag of TAG
availability for Monday session at TPAC [recorded in
[65]http://www.w3.org/2010/10/20-tagmem-irc]
[NEW] ACTION: Noah to have Amy reserve rooms for TAG F2F Feb 8-10
2011 recorded in [66]http://www.w3.org/2010/10/20-tagmem-irc]
[NEW] ACTION: Noah to inform TAG of TPAC meeting schedule [recorded
in [67]http://www.w3.org/2010/10/20-tagmem-irc]
[NEW] ACTION: Noah to Ping Thomas again on Dec. Privacy workshop
recorded in [68]http://www.w3.org/2010/10/20-tagmem-irc]
[NEW] ACTION: Noah to schedule group discussion of goals and roadmap
for metdata work [recorded in
[69]http://www.w3.org/2010/10/20-tagmem-irc]
[60] http://www.w3.org/2010/10/20-tagmem-irc
[61] http://www.w3.org/2010/10/20-tagmem-irc
[62] http://www.w3.org/2010/10/20-tagmem-irc
[63] http://www.w3.org/2010/10/20-tagmem-irc
[64] http://www.w3.org/2010/10/20-tagmem-irc
[65] http://www.w3.org/2010/10/20-tagmem-irc
[66] http://www.w3.org/2010/10/20-tagmem-irc
[67] http://www.w3.org/2010/10/20-tagmem-irc
[68] http://www.w3.org/2010/10/20-tagmem-irc
[69] http://www.w3.org/2010/10/20-tagmem-irc
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [70]scribe.perl version 1.135
([71]CVS log)
$Date: 2010/10/23 19:51:10 $
[70] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[71] http://dev.w3.org/cvsweb/2002/scribe/
=======================================
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TAG Face-to-face
21 Oct 2010
[2]Agenda
[2] http://www.w3.org/2001/tag/2010/10/19-agenda
See also: [3]IRC log
[3] http://www.w3.org/2010/10/21-tagmem-irc
Attendees
Present
Dan_Appelquist, Tim_Berners-Lee, John_Kemp, Yves_Lafon,
Ashok_Malhotra, Larry_Masinter, Noah_Mendelsohn, T_V_Raman,
Jonathan_Rees, Henry_Thompson
Regrets
Chair
Noah Mendelsohn
Scribe
Ashok Malhotra, Jonathan Rees
Contents
* [4]Topics
1. [5]HTML/XML Unification
2. [6]IRIEverywhere-27
3. [7]Metadata Architecture
4. [8]Design of APIs for Web Applications
5. [9]Privacy
6. [10]Redirecting to a secondary resource
7. [11]Pending, overdue, and open action items
* [12]Summary of Action Items
_________________________________________________________
<Ashok> Scribenick: Ashok
<scribe> Scribe: Ashok Malhotra
HTML/XML Unification
Noah: Goals are to decide what we can do to move ahead or decide not
to move ahead
... Tim the TPAC committee is waiting for you to tell them if you
want to talk about it
Tim: Can we agree to define the charter of the group here
... we have started a task force ... Raman asked for it
... asked Norm to join ... said yes
<noah> I think what Larry suggests is reasonable IF we can convince
ourselves that this could be a realistic effort, that we have a
sense of what timeframe for impact, etc. Then we can think about
soliciting participation.
Raman: We should not call it a TAG task force
<noah> Also, I think this can't be a volunteer effort -- I think the
point is that Tim, with our help, will pick a small, balanced set of
experts to see if some new avenue can be discovered.
Raman: the charter will determine who participates and who
participates will determine how well the task force does
Tim: Agree charter is most important ... will decide who joins and
how successful we are
<jar_> coordination?
Tim: Divergence of XML and HTML
LM: My understanding of this isuue ahs been hampered beacuse there
are no participants from XML community
... we need XML usecases etc.
Raman: We need people who are most affected
... Tim, you had a list on Tuesday
<noah> Noodling on charter: Goal is to develop specifically
technical proposals and/or best practices that would increase the
ability to 1) use XML tools to create and manipulate HTML and 2) to
include XML fragments in HTML and 3) to include HTML fragments in
XML.
Tim: --subset of HTML5 needed for simpler devices
- Impossible derive a RESTful API comapred to XForms ... cannot tell
waht data it transmits
<noah> Noodling on charter: Goal is to develop specific technical
proposals and/or best practices that would increase the ability to
1) use XML tools to create and manipulate HTML and 2) to include XML
fragments in HTML and 3) to include HTML fragments in XML.
<noah> Noodling on charter: Goal is to develop specific technical
proposals and/or best practices that would increase the ability to
1) use XML tools to create, manipulate and "round trip" HTML and 2)
to include XML fragments in HTML and 3) to include HTML fragments in
XML.
Tim: Also use XML tools to create HTML and load XML
<noah> Addition to the charter: The requirement is to do this in a
way that will be widely deployed.
Noah: Whether to push well-formed should wait until task force is
formed
Tim: What is important for XML folks is infoset and what is
important for HTML folks is DOM
Raman: Make sure you deliver good DOMs via good markup
Noah: The charter should start with broad success goals
<Zakim> noah, you wanted to discuss charter proposal
Noah: start by saying the taskforce has to find something that
widely accepted
LM: It is not a good idea to talk about XML community and HTML
community
... if we are successful there will be a single community
<noah> What I said more specifically was: the charter should require
a solution that will be widely deployed, for the stated purposes.
Achieving that will require the task force to confront the very
difficult technical challenges, e.g. that well-formedness is seen as
conflicting with existing practice, is cumbersome for some, and so
can't in general be required.
LM: some use cases such as EXI and DSig work for XML but not HTML
... perhaps increase scope of polyglot documents
Tim: Raman spoke about organizing the ultimate converence not a
quick fix
<noah> To my 3 charter points, I might add: attempt to increase the
set of documents that behave as polyglot/chameleon, I.e. that can be
served with reasonably compatible semantics, DOM, etc. as either
text/html or application/xhtml+xml
Raman: HTML5 spec is starting to add rules
... such as Table/Tbody
... Webkit will fix bad Table syntax
... and serialize correctly
... I think these kinds of rules will become common
... problems are with things like xml:id and id, xml:lang and lang
... leads to 2 worlds
Noah: XML community may need to move
Raman: Larry talks about tools ... HTML tools was IE
... XML tools are there and are used ... legacy
... You said creating HTML from XML is easy ... I don't think so
Noah: The XMLstuff is of value to some people ... they have deployed
code ... that is why we had trouble with stuff like XML 1.1
... Many of the changes would change the value proposition for XML
... they would resist change
<Zakim> ht, you wanted to disagree with TV's analysis: there are two
XML communities
<johnk> masinter: isn't the standard HTML <-> XML transformation the
thing (formerly?) known as XHTML5?
HT: There are 2 XML communities ... people who use XML as XML for
interprocess communication, not interested in human readers
... there is another community who care about human readers. The 2
communities use some of the same tooling but have different goals
<Zakim> masinter`, you wanted to talk about transformation gateway,
ask if their's a value to standardizing that
LM: XML/HML transformation gateways ... differences in the DOMs
<jar_> wannabe-commutative diagrams (html / xml / source / dom)
<raman> agree with ht. but the interesting case for convergence are
formats like rss or atom. So is Atom/RSS data or content? Today, the
content particle in rss/atom is html -- and is carried as a bag of
bytes --- not as something that can be parsed as xml.
<raman> agree with ht. but the interesting case for convergence are
formats like rss or atom. So is Atom/RSS data or content? Today, the
content particle in rss/atom is html -- and is carried as a bag of
bytes --- not as something that can be parsed as xml.
LM: How to apply XML DSig to Webpage?
<johnk> [13]http://wiki.whatwg.org/wiki/HTML_vs._XHTML
[13] http://wiki.whatwg.org/wiki/HTML_vs._XHTML
Tim: Including scripts?
LM: That's a kind of workflow where we do not know that the
standards work together
<Zakim> noah, you wanted to ask how this is positioned relative to
HTML5 specification development process
LM: use this kind of value-based reasoning to drive the taskforce so
it is nor percieved as an academic exercise
Tim: The Polyglot investigation did address that
<jar_> lm: Let's identify the real value of using XML, e.g. signed
content, and suggest that it would be awfully nice to get the same
value for HTML
Tim: there are some constraints ... I'm happy to live with these
constraints
... happy not to write scripts that use some DOM properties
... polyglot defines some rules and if you follow them everything
just works.
JK: Sceptical of that claim
<Zakim> noah, you wanted to ask how this is positioned relative to
HTML5 specification development process
Noah: The chairs will ask how this affects them logistically
... questions about process to complete specs, etc.
Tim: The task force will take the polyglot idea and take it further
... polyglot idea did not come from HTML5
... Do we feel about changing XML so the XML parser would use the
default namespace from the MIMe type
HT: I talked to Liam ... this may be acceptable as a change to XML
Yves: Include XML fragment in HTML ... this is the only one that
will have impact on HTML
Noah: Task force will decide what to recommend
Yves: Should the task force work on pussing XML fragments in HTML
<noah> NM: I think the task force should try to figure out which of
these specific changes, in XML or HTML specifications, would likely
be deployable and a win for the communities as a whole
HT: You edit the doc ... edit the SVG still works because using a
HTML5 parser ... then you cut it out and it fails
Yves: You have a serialized DOM ... issue on the tools not a
language problem
LM: View Source may have some options
<noah> 4 mins to go on this subject
Noah: Tim, do you have what you need re. talk at TPAC and deciding
whether and how to charter the task force?
Tim: GOAL of task force: Enable and enhance mixed XML/HTML workflows
... We have a good story and we can go ahead
... need 6 more folks
... Steps moving forward: Draft charter, circulate to TAG, Circulate
to candidate TF, Circulate to AB,
LM: We may also need an IG
HT: You may want a period of negotiation with the candidate TF
Break for 10 minutes
<DKA>
[14]http://edition.cnn.com/2010/TECH/mobile/10/20/html5.smartphone.a
pps/
[14] http://edition.cnn.com/2010/TECH/mobile/10/20/html5.smartphone.apps/
<DKA> HTML5 is the future.
<DKA> ( apparently )
IRIEverywhere-27
<noah> close ACTION-459
<trackbot> ACTION-459 Schedule F2F discussion of IRIbis status and
Larry's proposal closed
Noah: HT wanted a f2f update from Larry
<noah> ACTION-410?
<trackbot> ACTION-410 -- Larry Masinter to let the TAG know whether
and when the IRIEverywhere plan in HTML WG went as planned -- due
2010-11-01 -- OPEN
<trackbot> [15]http://www.w3.org/2001/tag/group/track/actions/410
[15] http://www.w3.org/2001/tag/group/track/actions/410
HT: The TAG should hear about the way in which you rearchitected the
way in which the specs will work
... what happened? Did the idea succeed.
LM: There is a spec ... above
... there is a WG chartered to finish the spec ... we are moving
forward
... There were 4 different things
<noah> Private conversation: DanA kindly agrees to integrate minutes
for Tuesday
IRI's could occur in:
XML
HTML
OTHERIRI
FORMALIRI -3987
scribe: LEIRI had its own IRI and had an algorithm for transforming
to FORMALIRI
... URI is a FORMAL URI but also lossy
HTML URI was not well defined ...
<DKA> [ Apropos to the privacy discusion: Google Engineer Builds
Facebook Disconnect (TechCrunch): [16]http://tcrn.ch/9zFyot ]
[16] http://tcrn.ch/9zFyot
Added "PRESENTATIONS" below HTML
scribe: what you write on the side of a bus is not a sequence of
codepoints
... impt to separate out the presentations from the sequence of
unicode characters
LM: Deprecate the idea that there is a set of chars that are not
allowed ... there is a syntax that determines what is allowed
IRI -> sequence of unicode parts
IRI components -> processing
<DKA> Image of whiteboard from XHTML-HTML taskforce discussion:
[17]http://www.w3.org/2001/tag/2010/10/xmlTaskforceWhiteboard.jpg
[17] http://www.w3.org/2001/tag/2010/10/xmlTaskforceWhiteboard.jpg
JR: There is a presentation, there are octets and then parts of the
IRI
IRI is a sequence of codepoints
scribe: someone has to pick a character encoding
<ht> iso-8859-1, etc.
LM: The parsing happens on the IRI and from that you get a set of
components and this is what you process
test
LM: What HTML was doing was not a syntactic item ... it was a
processing step ... step can know about document encoding
... We now have a document with correct structure but lot of the
details are still wrong
HT: The splitting into components is character independent
LM: There is a change proposal for HTML spec that points at this
Noah: How is HTML WG looking at this?
LM: Adam authored an alternate change proposal
... folks want this problem to go away
... 2 different versions of IDNA? how do we handle bi-di?
... for Bi-Di we need directional markers
... this is still up in the air
... trying to get critical mass
... There is a document ... still has bugs ... needs people to take
a look
HT: This is good stuff. If the politics get sticky let us know.
LM: Politics is sticky
... Need to change registry to register IRI schemes
Tim: How do I need to change RDF code ... now it normalizes the URI
LM: We did not change URIs
Tim: If it is not URI it is hex encoded
LM: If you had a Chinese assertions the hex encoded URI will not
work
Tim: This breaks 10 yrs worth of code
HT: The hex encoded URI will fail unless client libraries update
LM: It was a hard choice ... none of the choices were great ... I
think this was the best choice
<noah> ACTION-410?
<trackbot> ACTION-410 -- Larry Masinter to let the TAG know whether
and when the IRIEverywhere plan in HTML WG went as planned -- due
2010-11-01 -- OPEN
<trackbot> [18]http://www.w3.org/2001/tag/group/track/actions/410
[18] http://www.w3.org/2001/tag/group/track/actions/410
<noah> close ACTION-410
<trackbot> ACTION-410 Let the TAG know whether and when the
IRIEverywhere plan in HTML WG went as planned closed
<jar_> ACTION jar to assess potential impact of IRI draft on
RDF/XML, OWL, and Turtle
<trackbot> Created ACTION-487 - Assess potential impact of IRI draft
on RDF/XML, OWL, and Turtle [on Jonathan Rees - due 2010-10-28].
<jar_> action-487 due 2011-12-01
<trackbot> ACTION-487 Assess potential impact of IRI draft on
RDF/XML, OWL, and Turtle due date now 2011-12-01
Metadata Architecture
<jar_>
[19]http://www.w3.org/2001/tag/2010/10/metadata-arch-outline.txt
[19] http://www.w3.org/2001/tag/2010/10/metadata-arch-outline.txt
Noah: We need to discuss about how to proceed on Metadata
jar: Just typed this is in last night ... goal is to prevent bad
things from hapenning
... lots of metadata efforts
... is my list about right?
... Trying to put things into a framework
<DKA> Another metadata effort I have been involved with in the past:
PRISM -
[20]http://www.idealliance.org/industry_resources/intelligent_conten
t_informed_workflow/prism
[20]
http://www.idealliance.org/industry_resources/intelligent_content_informed_workflow/prism
Noah: Goal is to guide the community ...
jar: Options on how to add metadata ... how to choose
<DKA> Also - POWDER : [21]http://www.w3.org/TR/powder-dr/
[21] http://www.w3.org/TR/powder-dr/
jar: If I get guidance i can produce draft by early spring
Tim: These are things we can do and how to do it ... where are the
orange blobs [reference to diagram on whiteboard, blobs are research
areas]?
... crises or opportunities?
... I need a heat map
<Zakim> masinter`, you wanted to talk about: bad things that can
happen, other issues
<timbl> Threat level opportunity level
LM: Big space, stuff is moving
... preventing bad things has more urgency
... people choosing metadata vocabularies that are different to map
between ... same data. different languages
<timbl> Threat: Lack of harmonization of metadata ontology
<timbl> --Larry
LM: Vocabulary divergence
... the other is when you have multiple sources of metadata and how
to pick what you want
<timbl> Metadata services / indexes
<timbl> . . . SPARQL
LM: possible conflict between metadata sources ... metadata in lots
of different places
... we are at risk of W3C exacerbating the situation
... The outline is fine
Noah: Probes on what LM wants to proceed
Tim: Orange blog on create/curate formats?
<Zakim> ht, you wanted to ask about metadata defined how?
ht: metadata for what?
... what's the domain?
jar: Metadata is data about digital objects
<Zakim> masinter`, you wanted to point out media annotation working
group work
LM: There is a media annotations WG ... they have a document about
metadata and metadata resolution etc.
... perhaps ask if their idea of metadata and metadata resolution
matches ours
<ht> hst: "data about digital objects" is fine with me, against a
background of focussing/foregrounding the Information Science
community's view of what metadata/digital objects is/are
jar: Looks like a format ... for delivering they reference powder
... Easy answer is Semantic Web gives you an answer [JAR looking at
these minutes has a feeling he said "RDF" not "Semantic Web"]
<Zakim> timbl, you wanted to say that at the moment of course the
digital objects out there of great interest are [government] linked
open datasets. It is very timely to encourage work on
<timbl> [22]http://www.ckan.net/
[22] http://www.ckan.net/
Tim: UK Govt uses CKAN
Jar: You register things in it so that they can be found
Tim: Has an API ... not particularly RDF oriented ... cannot do Math
... Has a keywork query info
... Connect up people who are working on repositories with SPARQL
code
<DKA> Just looking at [23]http://www.w3.org/TR/mediaont-api-1.0/
(API for media annotation API) and thinking about in the context of
Web Application APIs and also in the context of the metadata
discussion...
[23] http://www.w3.org/TR/mediaont-api-1.0/
Ashok: Should the TAG recommend "use RDF (and OWL) for metadata and
SPARQL?
Tim explains 5 star rating for data
<noah> JAR: That's new in the outline: discussion of APIs to access
metadata
<timbl> + to talk about Jeni Tennison's work
<johnk> [24]http://code.google.com/p/rdfquery/ is Jeni Tennison's
rdfquery work
[24] http://code.google.com/p/rdfquery/
Tim: Emphasize, that RDF & SPARQL for data and for metadata
... Jeni's work ... RDF repository with SPARQL access
<ht> [25]http://www.legislation.gov.uk/
[25] http://www.legislation.gov.uk/
<DKA> Interesting blog post from Russell Beattie on microformats in
HTML5:
[26]http://www.russellbeattie.com/blog/html5-microdata-thoughts-on-s
emantic-data-mobile-adaption-and-facebook-fbml
[26]
http://www.russellbeattie.com/blog/html5-microdata-thoughts-on-semantic-data-mobile-adaption-and-facebook-fbml
Tim: typical user does not understand/use SPARQL
<jar_> this is off topic
Tim: there is an API that generates SPARQL
<jar_> very interesting but it has nothing to do specifically with
metadata
Noah: Pl. clarify what happens at client and what at the server
Tim: We need to say how to use the SPARQL
<Zakim> noah, you wanted to ask about going too far
Jar: How best to use the RDF stack is a goal and work in progress
... Here are the benefits you get if you use RDF and SPARQL
Noah: We could write good practice notes
jar: If someone is immersed in another metadata format we have to be
more nuanced
... make properly qualified statements
<Zakim> masinter`, you wanted to argue that "metadata" is a
different topic from "data"
<jar_> We lose credibility if our statement about the goodness of
RDF is too broad.
LM: If everyone uses RDF but different vocabularies that would be
bad. We want to say RDF is processable ... and use same vocabularies
<jar_> TBL said matching vocabularies is easy compared to getting
the information formatted in the same way. JAR said that in his
experience, format conversion is easy, relating semantics is very
hard.
LM: If data formats are different then it may not be a big problem
... Some more immediate things we could do ...
Tim: What will the finding be ... Larry is pointing out a hotspot
LM: Two areas hapenning in W3C where we can help - microformats vs.
RDFa and Media Annotations
Tim: Need some leadership in the area of metadata fo Linked Data
<noah> ACTION-282 Due 2011-04-01
<trackbot> ACTION-282 Draft a finding on metadata architecture. due
date now 2011-04-01
LM: Personally, I would put this as higher priority than Persistence
jar: [persistence is higher priority for JAR]
<noah> John to integrate Wed. minutes
<noah> Jonathan to integrate Thurs. minutes
<jar_> TBL: Star rating for linked data.
<jar_> 1. on web
<jar_> 2. machine readable
<jar_> 3. non-proprietary
<jar_> 4. in rdf
<jar_> 5. is linked
<scribe> Scribe: Jonathan Rees
<scribe> Scribenick: jar_
<noah> How are we doing with scribing this afternoon?
Design of APIs for Web Applications
Dan A introducing web app API topic
DKA: maybe aim for something could be useful to future people
working in the space
<noah> Where's the threat, and where is there confusion?
DKA: what architectural principles might apply to API design?
... What other technologies are core building blocks, things that
one is advised to build on?
... It would be beneficial to do some work in this area
masinter: Re APIs, there's a perspective that the web doesn't need
versions.
... With content, you have ignore-unknown and so on
... But how do you do API evolution without versions?
... How big is the API, how do you decompose it. What happens when
the language itself evolves?
... Are we talking only javascript, or also Java and so on?
... These are the kinds of questions I have in mind when we talk
about architecture.
<Zakim> noah, you wanted to talk about composability?
noah: TAG should emphasize things that help the whole to come out
right. Fit well compose with other things
... There is some of this in the Javascript world
... We could emphasize the things that have to do with the Web
<Zakim> masinter`, you wanted to ask some questions about versioning
of APIs, granularity of APIs, data structures, evolution of
JavaScript
<Zakim> timbl, you wanted to say Multi-lamguage APIs which the DOM
aimed for are sub-optimal for tight binding of language t the data.
2) versioning? Programmers cope with bits not being
noah: What happens when there are multiple events/handlers any of
which can fire (e.g.)
timbl: Back when, you were supposed to make an IDL, then bindings.
What programmers look for now is a much closer binding of API and
language (e.g. iterators). New pattern of higher-order functions.
... IDL may be too limited... short names are good, you can assume
names are scoped [unlike IDL style]...
... instead of calling a method on something, just iterate over
it... seems the way to go
<noah> I think IDL is motivated primarily when you want to support
multiple languages, such as VBScript. I agree with Tim, getting
JavaScript right, and benefiting from idiomatic constructs is the
right way to go.
ashok: Touches on: How do you save state? How do you communicate
with other apps? Storage? Authorization? We ought to coordinate this
work
<noah> By the way, Tim pointing out the JQuery/Dojo idiom of
chaining functions is a great example of using an overarching
architectural approach to get composability.
dka: Re inter-webapp communication, look at Open Ajax Hub. Creates a
secure environment for this.
... Between different frames
ashok: Example?
dka: 2 apps in different tabs, one wants to communicate with the
other
noah: Restaurant app + map app mashup
dka: Ashok, you were talking about a local app in browser wanting to
talk on an ODBC connection to a local database not in the browser?
Nobody working on that
noah: What if we *don't* work on this?
dka: Privacy is bigger and more urgent compared to APIs
<noah> NM: I tried to say, what do we lose or what do we slow down
if we work on this?
ht: EXT
jar: What about toolkits, if we were to work on this we might see
what these efforts are and if they're happy
noah: Put off til spring, do privacy in meantime? Or what?
<DKA> action-461?
<trackbot> ACTION-461 -- Daniel Appelquist to draft "finding" on Web
Apps API design -- due 2010-10-31 -- OPEN
<trackbot> [27]http://www.w3.org/2001/tag/group/track/actions/461
[27] http://www.w3.org/2001/tag/group/track/actions/461
dka: I'd like to talk to people at TPAC doing API design
<noah> . ACTION: Appelquist to solicit at TPAC perspectives on what
TAG could/should do on APIs
dka: to get better understanding of how TAG work would be received,
and get input
<noah> . ACTION: Appelquist to solicit at TPAC perspectives on what
TAG could/should do on APIs Due: 2010-11-09
<noah> ACTION-461 Due 2010-12-31
<trackbot> ACTION-461 Draft "finding" on Web Apps API design due
date now 2010-12-31
Privacy
<noah> ACTION: Appelquist to solicit at TPAC perspectives on what
TAG could/should do on APIs Due: 2010-11-09 [recorded in
[28]http://www.w3.org/2001/tag/2010/10/21-minutes#action01]
<trackbot> Created ACTION-488 - Solicit at TPAC perspectives on what
TAG could/should do on APIs Due: 2010-11-09 [on Daniel Appelquist -
due 2010-10-28].
ashok: We ought to produce something on evercookie thing quickly
dka: draw on recent posts to www-tag
... "privacy" is a big thing, maybe shift subject to user intent
<noah> NM: I like thinking about this first in terms of: there is a
risk that software will be able correlate events that the user does
not wish to have correlated. E.g. the same user who bought this
house at a real estate browsed for bars at some search site.
masinter: [see above] Really clearing private information is really
hard, you have to cleanse every server
... Someone might be confused about this
<noah> NM: We can explain that, among the reasons this causes
concern, is that such correlation can sometimes allow discovery of
information that the user might wish to keep private (I don't want
the people who are selling me the house to know that I drink a lot.)
dka: The scope in an ASAP statement should be limited to evercookie,
how standards community might respond
ashok: We could say: browsers ought to let you clear private
information. That's tricky to say
<Yves> think of spam, link to remove from "spam lists" that are
there to check the validity of emails... and the never-ending
spam/anti-spam race. same issue with tracking and cookies
<Zakim> ht, you wanted to ask about the connection with JAR's
perspective
ashok: ... what else could we soapbox about?
ht: Butting heads: You must be able to clear browser state / You
can't clear browser state
... That you're trying to protect your own private
<Zakim> noah, you wanted to discussing referring expression
ht: The way to achieve desired effect is to institute accountability
... [...] is not a referring expression
noah: Given that we can't plug all the holes, should we try to plug
any?
... We can say that there are other ways to look at the problem
... Can we settle that question?
... The steganography example (URI history list) is what pushed me
over
raman: As we go mobile, the trend is to be able to easily share
context... URIs communicated from browser to phone
<noah> NM: The key thing I said is that I think the TAG should start
by settling the question of whether Evercookie just shows that the
list of things to worry about is a bit longer than you thought, or
whether it indicates that we will not typically succeed in providing
effective protection at this time.
raman: Out of band info being put into local storage, will soon be
put into cloud storage. I predict all local storage will move to
cloud
... Users have conflicting requirements
... Bad guys will use same hooks to do bad things
<noah> NM: I tend to believe the latter. That being the case, we
need to then decide whether it's worth asking people to plug at
least some of the holes. My leaning is "yes, sometimes", Henry seems
to say "probably not", but I think that's the next discussion we
should have.
raman: This is a wakeup call. No easy answer
dka: Looks like a false dichotomy. Either you admit web privacy is
dead, or you plug a million holes
... There could be tactical approaches. Plug some holes, help a bit,
help users to make informed decisions
... also longer term work to be done on privacy, much bigger than
TAG, but TAG can play a role, workshops/intitiatives
<noah> . ACTION: Appelquist to prepare early draft of TAG thoughts
on implications of Evercookie. Due: 2010-12-08
dka: We can show leadership by saying something [appropriate /
reasoned / limited] about evercookie
<noah> ACTION: Appelquist to prepare early draft of TAG thoughts on
implications of Evercookie. Due: 2010-12-08 [recorded in
[29]http://www.w3.org/2001/tag/2010/10/21-minutes#action02]
<trackbot> Created ACTION-489 - Prepare early draft of TAG thoughts
on implications of Evercookie. Due: 2010-12-08 [on Daniel Appelquist
- due 2010-10-28].
yves: It's more like spam. Never ending battle. But we have to keep
fighting.
<noah> If my privacy is protected as well as I am insulated from
spam, then my life is one big open book.
yves: Explaining issue is important
... it's a tax
masinter: 'Privacy' is not the quantity we're trying to optimize
... Goal is to match what's happening with what's expected
... I send email to a list that I think is limited readership, is it
really?
... Put evercookies in that context and I'll be happy
noah: (administrative interrupt as DKA departs) Considering skipping
call next week (TPAC is the week after that)
ashok: Encrypt everything at a low level?
jar: Hal [Abelson] has been looking at tagging-based hardware to
support accountability
noah: Unknown people can't be held accountable
... they're piecing together information about me
masinter: We haven't done the threat analysis. Don't know what
problem to solve
noah: ...
masinter: They have my IP address and HTTP headers, what's new?
ht: The evercookies point was that the vulnerabilities were already
there
yves: Companies are buying one another, and otherwise sharing
information with one another
... so you get correlations
masinter: Clearing your cookies not only doesn't get you what you
need, it gets in the way of getting what you want
<Zakim> ht, you wanted to make the strategy point
(people use 'clear cookies' to logout / clear credentials, and it
often works)
ht: As far as new activity in this area might go, it shouldn't
confuse privacy with protecting private data
... If there are thought leaders giving a message that's the right
one, then we (W3C) could get behind it
noah: We have enough actions, yes?
<noah> ACTION: Noah and others(?) going to privacy workshop to
report back to the TAG? [recorded in
[30]http://www.w3.org/2001/tag/2010/10/21-minutes#action03]
<trackbot> Created ACTION-490 - And others(?) going to privacy
workshop to report back to the TAG? [on Noah Mendelsohn - due
2010-10-28].
jar: Given that we're not on top of thinking on this, how about if
someone gets educated by reading something (e.g. about Hal's ideas)
<noah> ACTION-490 Due 2010-12-21
<trackbot> ACTION-490 And others(?) going to privacy workshop to
report back to the TAG? due date now 2010-12-21
Redirecting to a secondary resource
A#B where A -> C#D
yves: Taxonomy of fragids
... FIrst case: book chapter. Also SVG file with multiple icons,
point to a particular icon
... I tested the SVG fragment case and it worked (and it's in the
spec)
timbl: In the python API, you don't have enough information
... x = urlib.urlopen('foo')
... s = x.read()
... x.headers
jar: I think Julian was saying the whole discussion is moot, since
the decision was made 10 years ago and published in the errata.
... So the time to review it would have been then. Cat's out of the
bag.
<Yves> [31]http://skrb.org/ietf/http_errata.html
[31] http://skrb.org/ietf/http_errata.html
jar: (To Yves) Then this SVG case is the example that I had asked
for?
(everyone trying to track down ietf commitment to this erratum)
(looking at archive's version of skrb.org)
<Yves>
[32]http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/
0115.html
[32]
http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0115.html
ht: Possible courses of ACTION: (1) Revert this change to Location:.
Does harm, no evidence of use. (2) We don't know if anyone's using
it, we don't have fragment combination rules, leave it in. (3) Here
are frag combination rules that cover particular cases, don't do it
otherwise (i.e. negative consequences will follow).
masinter: (4) You can have one fragment id, but not two.
ht: The people who set up a redirect are not the same as the people
who capture the fragid URI
... Or, people publish docs with names in them. I select something
that seems to have a name, click view fragment source, put together
a URI, and send it on to someone.
... It's not necessarily the case that there is coordination
masinter: You can do this, but something might break.
masinter (reworded by jar): If you deploy a 30x Location: C#D, then
be aware that anyone who creates a URI A#B, might be inconvenienced
(since there are no fragment combination rules).
scribe: (that is, A 30x redirects to C#D)
<timbl> [33]http://purl.org/ontology/bibo/Book
[33] http://purl.org/ontology/bibo/Book
masinter: There's a tendency to want to control both sides of the
conversation - MUSTs that apply to parties not constrained by the
spec in question
<timbl> $ curl -I [34]http://purl.org/ontology/bibo/Book
[34] http://purl.org/ontology/bibo/Book
<timbl> HTTP/1.1 302 Moved Temporarily
<timbl> Location:
[35]http://bibotools.googlecode.com/svn/bibo-ontology/tags/1.3/bibo.
xml.owl#Book
[35]
http://bibotools.googlecode.com/svn/bibo-ontology/tags/1.3/bibo.xml.owl#Book
yves: Case 2. Absolute fragment - exactly one place in the document.
... Compare xpointer, from one point in a doc, select something just
following, not same as selecting from whole document.
<timbl> >>> import urllib
<timbl> >>> x =
urllib.urlopen("[36]http://purl.org/ontology/bibo/Book")
[36] http://purl.org/ontology/bibo/Book
<timbl> >>> s = x.read()
<timbl> >>> s
<timbl> '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML
2.0//EN">\n<html><head>\n<title>400 Bad
Request</title>\n</head><body>\n<h1>Bad Request</h1>\n<p>The request
was invalid: the URI included an un-escaped hash
character</p>\n</body></html>\n'
<timbl> >>>
yves: Example with RDF: fragment defines something that's in the
document. Or javascript, where it's a script state.
... It's not really in the realm of the mime type
raman: The way I tried to reconcile this, think of it as an argument
to a client side function that deals with the fragid. In general,
it's an arg to some function on the page. If no such, then look for
element.
... Server/client not completely separate, since client is running
code that came from server
yves: Unpredictability leads to impossibility of a universal way to
define fragid combination.
<Yves>
[37]http://lists.w3.org/Archives/Public/www-tag/2010Oct/0036.html
[37] http://lists.w3.org/Archives/Public/www-tag/2010Oct/0036.html
yves: Best solution is to drop the original one. That's what most
browsers do, anyhow.
masinter: What if you redirect to a PDF, that has its own idea of
fragids.
ht: Right, that's the reason to drop the first fragid
yves: In case of redirect A#B to C, to be consistent you'd have to
drop the #B
noah: When I go to W3C, and I ask you from foo (instead of
foo.html), and that redirected to foo.html ... lots of places where
keeping the #B fragment is leveraged
ht: Maybe I was too quick to agree with Yves on the media type
question. The naive view is that the document is in a different
place. But really it's more like conneg
... It's still reasonable to apply the original fragid (#B in A#B
when A redirects to C#D)
<ht> In either case the presumption of consistent fragid
interpretation is legitimate
masinter: Don't redirect to [already typed into irc]
<ht> This justifies applying 'B' to C when A#B redirects to C
masinter: If you do conneg, don't do it where fragids mean different
things
<Yves>
[38]http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragi
d
[38] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragid
<Zakim> noah, you wanted to talk about see also
noah: In 303, second doc is clearly different, but 301 says the docs
are pretty much the same
ht: 90% cases. Where no fragid combination, we agree with both
situations, A->C#D and A#B where A->C.
... In the fragid combination case, it's allowed... but health
warning.
<noah> Therefore for A#B --303 Redirect to--> C#D, applying #B to
either C or (somehow) to C#D is highly suspect.
scribe apologizes, missing this
didn't scribe conversation between henry and tim
ht: propose: The TAG will not request HTTPbis WG to restrict
Location: to absolute URIs
... OK, that's a starting point
<Yves> (for the scribe it is
[39]http://trac.tools.ietf.org/wg/httpbis/trac/ticket/6 )
[39] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/6
timbl: Agree only on condition... that there is a sufficient health
warning
yves: Notes that Larry proposed such a health warning
ht: Let's table this
<timbl> ____ [begin demo] ____
<timbl> $ curl -L [40]http://purl.org/ontology/bibo/Book
[40] http://purl.org/ontology/bibo/Book
<timbl> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<timbl> <html><head>
<timbl> <title>400 Bad Request</title>
<timbl> </head><body>
<timbl> <h1>Bad Request</h1>
<timbl> <p>The request was invalid: the URI included an un-escaped
hash character</p>
<timbl> </body></html>
<timbl> $
<timbl> ____ [end demo] ____
jar: not willing to assent to Larry's warning today. May later
decide it's ok
noah: NOTE: Larry has made a proposal. We will take this up on a
call.
<ht> ____ [begin demo] ____
<ht> wget [41]http://purl.org/ontology/bibo/Book
[41] http://purl.org/ontology/bibo/Book
<ht> --2010-10-21 15:17:26-- [42]http://purl.org/ontology/bibo/Book
[42] http://purl.org/ontology/bibo/Book
<ht> Resolving purl.org (purl.org)... 132.174.1.35
<ht> Connecting to purl.org (purl.org)|132.174.1.35|:80...
connected.
<ht> HTTP request sent, awaiting response... 302 Moved Temporarily
<ht> Location:
[43]http://bibotools.googlecode.com/svn/bibo-ontology/tags/1.3/bibo.
xml.owl#Book [following]
[43]
http://bibotools.googlecode.com/svn/bibo-ontology/tags/1.3/bibo.xml.owl#Book
<ht> --2010-10-21 15:17:26--
[44]http://bibotools.googlecode.com/svn/bibo-ontology/tags/1.3/bibo.
xml.owl
[44]
http://bibotools.googlecode.com/svn/bibo-ontology/tags/1.3/bibo.xml.owl
<ht> Resolving bibotools.googlecode.com
(bibotools.googlecode.com)... 209.85.227.82
<ht> Connecting to bibotools.googlecode.com
(bibotools.googlecode.com)|209.85.227.82|:80... connected.
<ht> HTTP request sent, awaiting response... 200 OK
<ht> ____ [end demo] ____
<noah> close ACTION-462
<trackbot> ACTION-462 Write draft of best practices on redirection
for secondary resources (with help from Tim) closed
masinter: Opposed to telcon time on this
<noah> ACTION: Noah to schedule telcon attempt to formulate health
warning on secondary resource redirection noting Larry proposal in
21 Oct 2010 F2F record [recorded in
[45]http://www.w3.org/2001/tag/2010/10/21-minutes#action04]
<trackbot> Created ACTION-491 - Schedule telcon attempt to formulate
health warning on secondary resource redirection noting Larry
proposal in 21 Oct 2010 F2F record [on Noah Mendelsohn - due
2010-10-28].
<johnk> break
ACTION jar to Review Larry's health warning on redirection to
secondary resources and either agree or fix
<trackbot> Created ACTION-492 - Review Larry's health warning on
redirection to secondary resources and either agree or fix [on
Jonathan Rees - due 2010-10-28].
Pending, overdue, and open action items
[46]http://www.w3.org/2001/tag/group/track/actions/pendingreview
[46] http://www.w3.org/2001/tag/group/track/actions/pendingreview
<noah> CLOSE ACTION-473
<trackbot> ACTION-473 Draft possible TAG response on HTML
extensibility closed
johnk: I deferred announcement of my writing on action-417 pending
further work on web apps
ht: If I were at TPAC I'd like to drill on the DOM-based objections
to 'just like SVG'
<noah>
[47]http://www.w3.org/2001/tag/group/track/actions/overdue?sort=owne
r
[47] http://www.w3.org/2001/tag/group/track/actions/overdue?sort=owner
Take action-473 to email
action-454?
<trackbot> ACTION-454 -- Daniel Appelquist to take lead in
organizing outside contacts for TAG F2F -- due 2010-10-05 -- OPEN
<trackbot> [48]http://www.w3.org/2001/tag/group/track/actions/454
[48] http://www.w3.org/2001/tag/group/track/actions/454
<noah> close ACTION-454
<trackbot> ACTION-454 Take lead in organizing outside contacts for
TAG F2F closed
<noah> ACTION-116 Due 2011-02-11
<trackbot> ACTION-116 Align the tabulator internal vocabulary with
the vocabulary in the rules
[49]http://esw.w3.org/topic/AwwswDboothsRules, getting changes to
either as needed. due date now 2011-02-11
[49] http://esw.w3.org/topic/AwwswDboothsRules
action-280?
<trackbot> ACTION-280 -- John Kemp to (with John K) to enumerate
some CSRF scenarios discussed in Jun in Cambridge -- due 2010-10-11
-- OPEN
<trackbot> [50]http://www.w3.org/2001/tag/group/track/actions/280
[50] http://www.w3.org/2001/tag/group/track/actions/280
johnk: Had trouble figuring out which scenarios were meant.
jar: Sounds like a minutes failure
johnk: Couldn't find the 2x2 table that Dan wrote on the board
... I'll add a note to section 7
<johnk> I'll add a note to ACTION-417 noting that it should include
describing CSRF scenarios
<noah> Closing ACTION-280 because will pursue CSRF under ACTION-416
<noah> close ACTION-280
<trackbot> ACTION-280 (with John K) to enumerate some CSRF scenarios
discussed in Jun in Cambridge closed
ashok: Has there been any progress on CORS/UMP?
jar: many months ago. new WG in the works maybe
<noah> ACTION-355?
<trackbot> ACTION-355 -- John Kemp to explore the degree to which
AWWW and associated findings tell the interaction story for Web
Applications -- due 2010-10-05 -- OPEN
<trackbot> [51]http://www.w3.org/2001/tag/group/track/actions/355
[51] http://www.w3.org/2001/tag/group/track/actions/355
<noah> JK: Made some progress on that
johnk: Cases not covered by AWWW - some covered in email
... but it's not far enough along for me to want to review
<noah> ACTION: Noah to schedule discussion of interim work on
ACTION-355 Due: 2010-11-09 [recorded in
[52]http://www.w3.org/2001/tag/2010/10/21-minutes#action05]
<trackbot> Created ACTION-493 - Schedule discussion of interim work
on ACTION-355 Due: 2010-11-09 [on Noah Mendelsohn - due 2010-10-28].
<noah> ACTION-416?
<trackbot> ACTION-416 -- John Kemp to work on diagrams in "From
Server-side to client-side" section of webapps material -- due
2010-10-11 -- OPEN
<trackbot> [53]http://www.w3.org/2001/tag/group/track/actions/416
[53] http://www.w3.org/2001/tag/group/track/actions/416
<johnk>
[54]http://www.w3.org/2001/tag/2010/10/interaction-examples.html
[54] http://www.w3.org/2001/tag/2010/10/interaction-examples.html
johnk: I want to know what we're doing with webapps
noah: We decided to dive deep on storage, state, and apis
ashok: and we need a short overview based on stuff larry sent
masinter: We've talked about a framework / broad outline; and a few
things that fit into it
<noah> also diving on privacy
noah: Where to draw the line between work on storage and work on
privacy?
<DKA> IMO privacy considerations should be part of storage document.
masinter: I'd like a way to think about relationship between client
side and server side processing and how things move from one to the
other
johnk: I put some diagrams up, see
[55]http://www.w3.org/2001/tag/2010/04/WebApps.html
[55] http://www.w3.org/2001/tag/2010/04/WebApps.html
masinter: diagrams are fine for now. let's move on
ashok: I thought the diagrams with words around them would
constitute an intro to the web apps work.
timbl: Semantics of diagrams unclear
<noah> ACTION-416 Due 2011-03-01
<trackbot> ACTION-416 Work on diagrams in "From Server-side to
client-side" section of webapps material due date now 2011-03-01
<noah> Pushing out 416 pending better idea of what if anything is
needed.
<noah> ACTION-355 Due 2011-01-02
<trackbot> ACTION-355 Explore the degree to which AWWW and
associated findings tell the interaction story for Web Applications
due date now 2011-01-02
<noah> ACTION-472?
<trackbot> ACTION-472 -- Larry Masinter to update the mime-draft,
due 2010-10-12 -- due 2010-10-07 -- OPEN
<trackbot> [56]http://www.w3.org/2001/tag/group/track/actions/472
[56] http://www.w3.org/2001/tag/group/track/actions/472
<noah> ACTION-472 Due 2011-12-01
<trackbot> ACTION-472 Update the mime-draft, due 2010-10-12 due date
now 2011-12-01
<noah> ACTION-442?
<trackbot> ACTION-442 -- Ashok Malhotra to try and integrate NM and
TVRs words into a coherent draft -- due 2010-09-09 -- OPEN
<trackbot> [57]http://www.w3.org/2001/tag/group/track/actions/442
[57] http://www.w3.org/2001/tag/group/track/actions/442
<noah> AM: Overtaking by ACTION-481 or 482
<noah> close ACTION-442
<trackbot> ACTION-442 Try and integrate NM and TVRs words into a
coherent draft closed
<noah> ACTION-468?
<trackbot> ACTION-468 -- Noah Mendelsohn to invite Thinh to telcon
where Tim will be available to discuss "forbidding of hyperlinking"
-- due 2010-10-05 -- OPEN
<trackbot> [58]http://www.w3.org/2001/tag/group/track/actions/468
[58] http://www.w3.org/2001/tag/group/track/actions/468
<noah> Tim is likely 3 Dec and 10 Dec
<noah> ACTION-468?
<trackbot> ACTION-468 -- Noah Mendelsohn to invite Thinh to telcon
where Tim will be available to discuss "forbidding of hyperlinking"
-- due 2010-10-05 -- OPEN
<trackbot> [59]http://www.w3.org/2001/tag/group/track/actions/468
[59] http://www.w3.org/2001/tag/group/track/actions/468
<noah> Tim OK 18 Nov, 2 Dec
<noah> ACTION-468 Due 2010-11-16
<trackbot> ACTION-468 Invite Thinh to telcon where Tim will be
available to discuss "forbidding of hyperlinking" due date now
2010-11-16
<noah> close ACTION-474
<trackbot> ACTION-474 Ask Raman to set up phone at F2F closed
<noah> close ACTION-465
<trackbot> ACTION-465 Schedule F2F discussion of ACTION-282, "which
metadata mechanisms to use when". Get reading list from Larry and
www-tag. closed
<noah> ACTION-429
<noah> ACTION-201
<noah> ACTION-201?
<trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW
discussions -- due 2010-10-05 -- OPEN
<trackbot> [60]http://www.w3.org/2001/tag/group/track/actions/201
[60] http://www.w3.org/2001/tag/group/track/actions/201
<noah> JAR: Will do for next F2F
action-201 due 2011-01-25
<trackbot> ACTION-201 Report on status of AWWSW discussions due date
now 2011-01-25
<noah> close ACTION-429
<trackbot> ACTION-429 Work on arrangements for a TAG F2F, probably @
Google early Oct (self-assigned) closed
<noah> Noticed that ACTION-482 is redundant with ACTION-475
<noah> close ACTION-482
<trackbot> ACTION-482 Write a draft on client-side storage with help
from DanA Due: 2010-11-30 closed
<noah> close ACTION-485
<trackbot> ACTION-485 Have Amy reserve rooms for TAG F2F Feb 8-10
2011 closed
<noah> close ACTION-483
<trackbot> ACTION-483 Inform TAG of TPAC meeting schedule closed
<noah> close ACTION-486?
<noah> close ACTION-486
<trackbot> ACTION-486 Schedule group discussion of goals and roadmap
for metdata work closed
<noah> ACTION-381?
<trackbot> ACTION-381 -- Jonathan Rees to spend 2 hours helping Ian
with [61]http://www.w3.org/standards/webarch/ -- due 2010-11-01 --
OPEN
[61] http://www.w3.org/standards/webarch/
<trackbot> [62]http://www.w3.org/2001/tag/group/track/actions/381
[62] http://www.w3.org/2001/tag/group/track/actions/381
<noah> ACTION-381 Due 2010-12-01
<trackbot> ACTION-381 Spend 2 hours helping Ian with
[63]http://www.w3.org/standards/webarch/ due date now 2010-12-01
[63] http://www.w3.org/standards/webarch/
<noah> ACTION-487?
<trackbot> ACTION-487 -- Jonathan Rees to assess potential impact of
IRI draft on RDF/XML, OWL, and Turtle -- due 2011-12-01 -- OPEN
<trackbot> [64]http://www.w3.org/2001/tag/group/track/actions/487
[64] http://www.w3.org/2001/tag/group/track/actions/487
<noah> ACTION-478?
<trackbot> ACTION-478 -- Jonathan Rees 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 -- due 2010-10-27 -- OPEN
<trackbot> [65]http://www.w3.org/2001/tag/group/track/actions/478
[65] http://www.w3.org/2001/tag/group/track/actions/478
<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> [66]http://www.w3.org/2001/tag/group/track/actions/476
[66] http://www.w3.org/2001/tag/group/track/actions/476
<noah> ACTION-23?
<trackbot> ACTION-23 -- Henry S. Thompson to track progress of #int
bug 1974 in the XML Schema namespace document in the XML Schema WG
-- due 2010-11-30 -- OPEN
<trackbot> [67]http://www.w3.org/2001/tag/group/track/actions/23
[67] http://www.w3.org/2001/tag/group/track/actions/23
<timbl> I wonder whether
[68]http://www.w3.org/2001/tag/group/track/issues/46 has been
overtaken by events - no one is doing XML 1.1, only XML 1.0 erratum
[68] http://www.w3.org/2001/tag/group/track/issues/46
ADJOURNED
Summary of Action Items
[NEW] ACTION: Appelquist to prepare early draft of TAG thoughts on
implications of Evercookie. Due: 2010-12-08 [recorded in
[69]http://www.w3.org/2001/tag/2010/10/21-minutes#action02]
[NEW] ACTION: Appelquist to solicit at TPAC perspectives on what TAG
could/should do on APIs Due: 2010-11-09 [recorded in
[70]http://www.w3.org/2001/tag/2010/10/21-minutes#action01]
[NEW] ACTION: Noah and others(?) going to privacy workshop to report
back to the TAG? [recorded in
[71]http://www.w3.org/2001/tag/2010/10/21-minutes#action03]
[NEW] ACTION: Noah to schedule discussion of interim work on
ACTION-355 Due: 2010-11-09 [recorded in
[72]http://www.w3.org/2001/tag/2010/10/21-minutes#action05]
[NEW] ACTION: Noah to schedule telcon attempt to formulate health
warning on secondary resource redirection noting Larry proposal in
21 Oct 2010 F2F record [recorded in
[73]http://www.w3.org/2001/tag/2010/10/21-minutes#action04]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [74]scribe.perl version 1.135
([75]CVS log)
$Date: 2010/10/29 17:06:05 $
[74] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[75] http://dev.w3.org/cvsweb/2002/scribe/
Received on Saturday, 30 October 2010 14:29:59 UTC