W3C home > Mailing lists > Public > www-tag@w3.org > October 2010

Minutes of the TAG F2F of 19-21 October 2010 are now ready for review

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Sat, 30 Oct 2010 10:29:26 -0400
Message-ID: <4CCC2BC6.5060403@arcanedomain.com>
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.


[1] http://www.w3.org/2001/tag/2010/10/19-agenda


       [1] http://www.w3.org/

                                - DRAFT -

               Technical Architecture Group Teleconference

19 Oct 2010


       [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


           Daniel Appelquist, Tim Berners-Lee, Yves Lafon, Ashok
           Malhotra, Larry Masinter, Noah Mendelsohn, T V Raman,
           Jonathan Rees, Henry S. Thompson


           Noah Mendelsohn

           Henry S. Thompson, Daniel Appelquist


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

    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
    ... So our role is to articulate policies in a way that are

    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
    ... We should try to build on that kind of example

    TVR: Just emphasising that TAG impact has to be based on W3C

    <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


    <trackbot> ACTION-430 -- Ashok Malhotra to propose a plan for his
    contributions to section 5: Client-side state -- due 2010-09-09 --

    <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

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


      [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

    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

    <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

    <noah> Should we walk through the document?

    TBL: Privacy is really important and current, we've had all these
    ... 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
    ... 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

    <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

    <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

    <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

    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

    <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

    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

    [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

    TVR: Over time they are merging -- the distinction is only in your

    TBL: One has a URI and the other doesn't

    TVR: I can write an android app which jumps in and out of the

    <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

    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

    <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

    <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

    [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"
    ... That's a separate discussion from the one about what's needed
    for sharing across applications -- that's harder

    [NM: Short break]


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

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

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

    [25]http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5 good

      [25] http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5

    <Zakim> masinter, you wanted to disagree with Noah and agree with

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


      [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

    [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

    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


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

    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

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

    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.

    ml-04.html section 5


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


    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

    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

    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

    <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

    <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

    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

    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

    <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

    <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

    <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

    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

    <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

    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

    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

    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

    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

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

    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.

    <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

    <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

    <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

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

    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

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

    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

    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

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


    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

    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

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

    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

    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

    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

    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.


      [32] http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html


    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

    larry: working group chairs are interested in having you [adam]
    write a draft that they could incorporate as a working group work

    [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

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


      [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] http://www.w3.org/

                                - DRAFT -

               Technical Architecture Group Teleconference

20 Oct 2010


       [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


           Ashok Malhotra, Dan Appelquist, Larry Masinter, T.V. Raman
           (Rohit Khare), Tim Berners-Lee, Yves Lafon, Jonathan Rees,
           Henry Thompson, Noah Mendelsohn, John Kemp

           None recorded

           Noah Mendelsohn

           John Kemp, Larry Masinter


      * [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


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

    <raman> .

    JAR: summarizing my memo from last week -
    ... 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
    ... 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
    ... so we can legitimately endorse publishing mappings from other
    schemes to HTTP URIs

    <ht> [E]nsure that actionable http URI manifestations are available

    <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

    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

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

    <jar_> ht: If you get a 200 _from us_, then *we warrant* (we the
    domain owner) that the response is authoritative


    <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



    <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

    <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

    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.

    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

    <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


Web Apps Architecture


      [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


    NM: workshop coming up in December on this topic:

      [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


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

    <DKA> Nick Doty's paper:

      [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

    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
    ... my view is that we should push back on this issue
    ... 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
    ... 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)

    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/

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

    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?


    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

    TBL: lot of interest in making such statements (as noted in previous
    ... 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

    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

    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

    <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

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

    <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
    ... people have to think about the amount of time they have on time
    ... 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


      [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

    <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

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

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

    <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

    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


    <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


      [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



    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

      [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

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

    <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

    <trackbot> Created ACTION-481 - Update client-side state document
    with help from Raman Due: 2010-11-30 [on Ashok Malhotra - due

    <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

    <trackbot> Created ACTION-482 - Write a draft on client-side storage
    with help from DanA Due: 2010-11-30 [on Ashok Malhotra - due

    <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

    <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

    <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

    <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

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

    <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
    [NEW] ACTION: Ashok to write a draft on client-side storage with
    help from DanA Due: 2010-11-30 [recorded in
    [NEW] ACTION: Henry to organize meeting on persistence of domains
    due: 2010-02-28 [recorded in
    [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
    [NEW] ACTION: Noah to alert chairs, ac-forum, www-tag of TAG
    availability for Monday session at TPAC [recorded in
    [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

      [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] http://www.w3.org/

                                - DRAFT -

                            TAG Face-to-face

21 Oct 2010


       [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


           Dan_Appelquist, Tim_Berners-Lee, John_Kemp, Yves_Lafon,
           Ashok_Malhotra, Larry_Masinter, Noah_Mendelsohn, T_V_Raman,
           Jonathan_Rees, Henry_Thompson


           Noah Mendelsohn

           Ashok Malhotra, Jonathan Rees


      * [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

    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

    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

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


      [14] http://edition.cnn.com/2010/TECH/mobile/10/20/html5.smartphone.apps/

    <DKA> HTML5 is the future.

    <DKA> ( apparently )


    <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
    ... There were 4 different things

    <noah> Private conversation: DanA kindly agrees to integrate minutes
    for Tuesday

    IRI's could occur in:




    FORMALIRI -3987

    scribe: LEIRI had its own IRI and had an algorithm for transforming
    ... 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
    ... 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

    JR: There is a presentation, there are octets and then parts of the

    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


    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

    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


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


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

    <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

      [23] http://www.w3.org/TR/mediaont-api-1.0/

    Ashok: Should the TAG recommend "use RDF (and OWL) for metadata and

    Tim explains 5 star rating for data

    <noah> JAR: That's new in the outline: discussion of APIs to access

    <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


    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

    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

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

    <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

    <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

    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


    <noah> ACTION: Appelquist to solicit at TPAC perspectives on what
    TAG could/should do on APIs Due: 2010-11-09 [recorded in

    <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

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

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

    <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

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

    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

    <trackbot> Created ACTION-490 - And others(?) going to privacy
    workshop to report back to the TAG? [on Noah Mendelsohn - due

    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

    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

    <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

    (everyone trying to track down ietf commitment to this erratum)

    (looking at archive's version of skrb.org)



    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:


    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 =

      [36] http://purl.org/ontology/bibo/Book

    <timbl> >>> s = x.read()

    <timbl> >>> s

    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

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


      [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

    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


      [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

    <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

    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

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

    <ht> Connecting to purl.org (purl.org)||:80...

    <ht> HTTP request sent, awaiting response... 302 Moved Temporarily

    <ht> Location:
    xml.owl#Book [following]


    <ht> --2010-10-21 15:17:26--


    <ht> Resolving bibotools.googlecode.com

    <ht> Connecting to bibotools.googlecode.com
    (bibotools.googlecode.com)||: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

    <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

    <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

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


      [47] http://www.w3.org/2001/tag/group/track/actions/overdue?sort=owner

    Take action-473 to email


    <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


    <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

    <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


      [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

    <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

    johnk: I put some diagrams up, see

      [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

    <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

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

      [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


Summary of Action Items

    [NEW] ACTION: Appelquist to prepare early draft of TAG thoughts on
    implications of Evercookie. Due: 2010-12-08 [recorded in
    [NEW] ACTION: Appelquist to solicit at TPAC perspectives on what TAG
    could/should do on APIs Due: 2010-11-09 [recorded in
    [NEW] ACTION: Noah and others(?) going to privacy workshop to report
    back to the TAG? [recorded in
    [NEW] ACTION: Noah to schedule discussion of interim work on
    ACTION-355 Due: 2010-11-09 [recorded in
    [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

    [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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:08 UTC