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

Draft minutes of TAG F2F of 7-9 June 2010

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Wed, 16 Jun 2010 14:34:39 -0400
Message-ID: <4C19193F.3090408@arcanedomain.com>
To: "www-tag@w3.org" <www-tag@w3.org>
The TAG held a three day face-to-face meeting last week in London, from 
7-9 June 2010.  Unapproved draft minutes are now linked from the agenda 
[1]; the referenced files with the minutes for the individual days are 
at [2-4], and are appended in text-only form below.

TAG members are encouraged to review these for accuracy, and to either 
propose or check in edits as necessary.  Thank you.


[1] http://www.w3.org/2001/tag/2010/06/07-agenda
[2] http://www.w3.org/2001/tag/2010/06/07-minutes.html
[3] http://www.w3.org/2001/tag/2010/06/08-minutes.html
[4] http://www.w3.org/2001/tag/2010/06/9-minutes.html



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

                                 TAG F2F

07 Jun 2010


       [2] http://www.w3.org/2001/tag/2010/06/07-agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2010/06/07-tagmem-irc


           Jonathan_Rees, Noah_Mendelsohn, Ashok_Malhotra,
           Henry_Thompson, Daniel_Appelquist, TimBL, Yves_Lafon,


           Noah Mendelsohn

           Jonathan Rees, Yves


      * [4]Topics
          1. [5]Convene, review agenda
          2. [6]Web Applications: Overview
          3. [7]HTML / XML Unification
          4. [8]Domain name persistence (workshop planning)
          5. [9]Web Applications: Client-side state
          6. [10]Web Applications: Security
      * [11]Summary of Action Items

    <jar> convening

    <jar> scribe: Jonathan Rees

    <jar> scribenick: jar

Convene, review agenda

    Welcome Yves to the TAG

    F2F Main Goals:

    Make progress on writing related to Web Application Architecture

    XML / HTML integration

    Other technical topics

    noah: Question: what is the best form for our publications? recs,
    findings, blogs
    ... Let's get things written, push them out, then figure out their
    disposition (finding etc)
    ... Move domain name discussion from Tues to Mon

    ht: My goal was to brainstorm with a few (non-TAG) people on whether
    a more substantial meeting for consensus building is worthwhile
    ... Kevin Ashley, new director of DCC (digital curation center)

    <ht> Helen Hockx-Yu

    ht: Helen is from British Library

    (discussion of agenda, how to involve John K and others who have to
    call in)

Web Applications: Overview

    <DKA> [12]http://www.w3.org/2001/tag/2010/05/web-apps-notes.html

      [12] http://www.w3.org/2001/tag/2010/05/web-apps-notes.html

    dka: (talking from projected page -- follow above link)
    ... TAG could act as a 'lens' relating frontline work to broader
    ... Robin Berjon has been helpful
    ... Look at how how 'web applications' are being used in the field
    ... Originally people used GET... maybe not always in the best way
    ... Look at patterns of web app usage, say here's how they use the
    artifacts of web arch. Maybe this would be useful
    ... relation of messaging protocols to webarch - e.g. in social

    timbl: Messages vs. information space

    dka: e.g. Websockets is making this connection; that's interesting

    ht: +1 to drilling down enough to understand how XMPP addresses

    timbl: Pattern approach is good, say: If you use these protocols in
    this way you get this value.
    ... Applying this to web apps arch, there are many different areas,
    so [difficult]
    ... Taxonomies are ratholes...

    ht: People are inventing new things faster than we can classify them

    dka: People know REST, and ask what can the TAG add to the REST

    timbl: REST used to mean web + Fielding... now there are new
    patterns that build on this (e.g. odata, JSON, SPARQL patterns)

    noah: There's a level where we might say here's the architecture
    pattern, that connects client side & server side use of URIs
    ... Raman is giving interesting particular examples; [that's a
    second level]
    ... connect the 2 levels (architectural patterns & usage patterns)

    dka: I'm influenced by what we're doing in mobile web best practices
    group. Look into applying some of that methodology. Here's a usage,
    evaluate it, does it lead to a good result?

    timbl: often TAG work has been triggered by a very specific issue.
    Intense discussion, followed sometimes by saying it's OK.

    dka: Where can we have an activist agenda?

    noah: Our mandate is architecture... the web is an information
    space, much of the value comes from linking
    ... network effects

    dka: The 'cool uris don't change' resonates with people, they know
    w3c says this

    yves: Hard to link into a silo. Entertainment industry, for example,
    tends to make monolithic [insular] apps

    ashok: Is it lack of education, or is it business reasons?

    timbl: One concern about web apps is that they're too slow, this
    motivates things like app stores [native applications that could
    have been web apps]

    noah: The native apps are less clunky, little things

    timbl: We can [try to] clean up the web... [or] we could push for
    very hot web apps...

    ht: Many of these "you need specific browser X to look at this page"
    errors are false - the page works fine if you edit out the browser
    detection code

    timbl: (writing on white board, 3rd item in list after 'very hot
    apps') Decent social networking (socially aware storage; P2P)

    dka: I care about this last one, but I wouldn't put it under the
    topic of web apps

    noah, timbl: "For more, see the facebook page"

    ht: But then it is on the web, right?

    timbl: The problem is that the garden center is committed to FB
    being their ISP

    dka: re security, I've been focusing on DAP, GEO
    ... in widgets, there's the concept of a feature having a URI (e.g.
    the geolocation)
    ... this mirrors what app stores are trying to do. E.g. "this app
    wants to access you camera and location, ok?"

    noah: There are 3 levels of apps, app store, drive-by, widgets (with
    install step)

    dka: What constitutes a web app?

    ht: we talked about this in Cambridge, with John K

    timbl: negotiating the interchange of data between otherwise
    untrusted parties. An install is part of a trust system. The
    dominant web sites are ones that get trusted.
    ... different [orthogonal] from technical questions, such as
    shuffling data, caching

    noah: Users think they know what it means to install something. At
    install points they expect these annoying questions

    ashok: There can be problems if your situation changes (you don't
    want to allow use at a particular location, etc)

    noah: Tension between install step & on-the-spot decision making

    dka: Is there a middle way?
    ... People who are building widgets think of them as app containers,
    maybe [missed]

    yves: You want a local storage of [privacy/security] properties that
    can be examined and changed

    timbl: BT open zone
    ... there's an assumption that the domain is a principal ...
    ... individuals (social entities) and orgs are principals
    ... and then there are lumps of software - also treated as
    ... Would be good if the TAG looked at this... maybe recommend
    keys... the user interface is the hard part

    ht: It always comes back to the question of principals. These
    systems founder because of the identity not being useful to you.
    ... That doesn't tell you whether you should accept content from
    that principal.

    jar: Lampson emphasizes accountability

    ashok: Certs are often meaningless



    noah: PKI, Verisign but also PGP, Lotus Notes, integrated UI... PKI
    is a low level building block

    jar: Lampson article is cynical, interesting even if you don't agree

    timbl: The CORS idea seems bizarre to me, isn't the web public
    anyhow, why should scripts be different from other agents? - but
    it's a reputation system

    yves: Host X is fine for some things, but what if I don't like their
    tracking system?...

    dka: Let's look at the list, think about priorities

    Break for 15 minutes.

    <DKA> FYI - art heist blog article in NYT I was referring to
    earlier: [14]http://nyti.ms/d7qjaW context: freedom of the
    Internet, also privacy]

      [14] http://nyti.ms/d7qjaW


    Agenda shuffling

HTML / XML Unification

    <DKA> msg ht let me know if you think guests this afternoon will
    want internet access - if so, I need their email addresses if
    possible so I can get them passwords.

    <DKA> hrm

    noah: There've been repeated efforts on tag soup / html moving
    ... Raman had nominated TimBL to convene some kind of group to
    tackle this problem

    timbl: When Raman said the TAG was ineffective, I said what should
    be done?
    ... I've wanted to bring the XML and HTML forks back together
    ... Making a client has been made more difficult, with two stacks
    ... re mime types, Larry has said to fix it by fixing incentives ...
    ... we want a culture where it's considered good to clean things up
    ... maybe we'll try and fail
    ... So how can we clean this up.
    ... E.g. maybe fix the validator, so it would say "you could do such
    and such and then it would work with so and so client"
    ... To what extent do you move HTML toward XML, or XML toward HTML
    ... One end of the scale, non-nested close tags are silly, we can
    just say it's not OK
    ... On the other hand, default namespaces seem really convenient
    ... thus a range of attitudes depending on feature
    ... Possibility of a group with representation from both
    communities, people who understand issues deeply
    ... I've wanted to do this, but have felt there hasn't been backing.
    TAG support would be helpful

    <Zakim> ht, you wanted to mention the widespread use of XML
    toolchains in web/document management environment

    ht: Yes

    <DKA> +1 to bringing together moderates rather than extremists.

    <noah> I don't think moderates/extremists is the point. In fact,
    most of the people in the community I think have important
    perspectives. I think we need to bring together experts who
    understands the needs of the communities and the details of the

    ht: I've become aware that there's a big community that has bought
    into XML toolchains.
    ... But this doesn't count with HTML5 community because they're not
    building web apps. Instead they're making documents

    timbl: Example website?

    ht: Many of the drivers for HTML are trying to make the browser the
    application delivery platform
    ... The member participation in XHTML2 was from info delivery bus,
    not app deliv bus (yes, this is a specious distinction)
    ... There's overlap but these are different communities
    ... We mustn't leave the XML community behind. They bought into XML,
    and they get no benefit from HTML5
    ... They're shipping XHTML. They're uncertain about what would
    happen if they moved to HTML5

    <Zakim> DKA, you wanted to give a brief counter-example...

    dka: When we launched VF5 portal over browser on phone, that was
    based on an XML toolchain
    ... news, weather, horoscope - info sources don't want to build
    their own mobile sites, so we say, give us XML (partner markup) and
    we'll take care of it

    <ht> Here's an example of an all XML toolchain-produced website,
    managed using the Factonomy product I mentioned -- the site owners
    (almost) never see markup, but maintain and augment the site via
    form-based interfaces: [15]http://www.scottishhumanrights.com/

      [15] http://www.scottishhumanrights.com/

    dka: XSLT, WML, XHTML
    ... Now, the devices have grown up, the clients have more mature
    browsers, the info providers now have skills, so portal
    infrastructure may have a diminishing role
    ... Portal is evolving toward a directory

    noah: compare AOL, Yahoo! ?

    dka: Maybe this story gives a data point
    ... If it's easier for an intermediary to use HTML5, they're going
    to gravitate toward it

    timbl: A little person will get drupal ...

    <timbl> .. and hope that drupal works well with mobile

    <timbl> So the CMSs (open source and other) have to be\ fixed to
    work with mobile.

    <Zakim> ht, you wanted to present the above example

    ht: SHR writes no documents, just adds, organizes. Skins and layouts
    chosen from menu. The toolchain pulls both structure and content out
    of database and renders it in XHTML
    ... javascript is used to make site look same in all browsers ...

    <Zakim> noah, you wanted to noodle on JSON

    noah: Why was XML brought to W3C? Because hope was that it was to be
    used generally on the web
    ... Losing to JSON et al.

    <ht> HST wonders how sure you are that XML is (still) losing to JSON
    -- I hear less about it than I used to, and more about ATOM

    noah: the HTML5 app builders are not using XML ...

    timbl: RSS, ATOM
    ... there's lots of XML on the web... Word ...
    ... issue is important to anyone who writes scripts, has to deal
    with two different DOMs

    <timbl> SVG, DOCX

    yves: JSON has implied datatypes; XML datatypes are complex. JSON
    easier, natural
    ... compound document is a hard problem, huge problem in XML/HTML

    timbl: If people are moving data around, the direction to go is to
    standardize some way to map JSON to/from RDF

    ht: parsing XML is faster than parsing JSON...

    noah: transient effect

    <timbl> ht, pointers please!!!!

    ht: (that was just a footnote)

    <ht> [16]http://performance.survol.fr/2008/04/json/

      [16] http://performance.survol.fr/2008/04/json/



    <noah> JAR: Somehow reminds me of the LISP vision: universal format
    for data [did I get that right?]

    <noah> JAR: RDF somewhat the same

    <noah> JAR: Seems there's a constant struggle around getting data
    sent around in a machine processable way, and integrated with UI

    <ht> [18]http://labs.mudynamics.com/2009/05/01/json-xml-performance/

      [18] http://labs.mudynamics.com/2009/05/01/json-xml-performance/

    <ht> [19]http://ejohn.org/apps/jsonvxml/jsonvxml.png

      [19] http://ejohn.org/apps/jsonvxml/jsonvxml.png

    ht: [cleaning up html ...] validator should give positive feedback,
    feedback directed to the authors ... this seems promising
    ... What is the benefit we're trying to achieve? What is the
    motivating headline? We want to make the web (fill in blank)?

    timbl: simpler, cleaner?

    <ht> Whitepaper about short- and long-term benefits

    timbl: benefits, motto

    <ht> And then a catchphrase similar to "cool URIs don't change"

    timbl: Since 2 years ago, progress on polyglot documents, important
    idea & set of use cases
    ... Many discussions on namespaces

    <ht> The survival of polyglot as a 1st-class citizen is what really
    matters for the XML-tool-chain-doc-management stuff I've been
    banging on about

    timbl: strategy?

    jar: Task force vs. working group vs. other - let's be clear
    . action timbl to Create a task force on XML / HTML integration

    action timbl to Create a task force on XML / HTML convergence

    <trackbot> Created ACTION-437 - Create a task force on XML / HTML
    convergence [on Tim Berners-Lee - due 2010-06-14].

    action-437 due in one month

    <trackbot> ACTION-437 Create a task force on XML / HTML convergence
    due date now in one month
    . RESOLVED: The TAG recommends the formation of a task force to
    drive the reunification of XML and HTML

    RESOLUTION: The TAG recommends the formation of a task force to
    drive the reunification of XML and HTML

    (passed by general acclaim)

    <ht> OK, I have found the beginning of the thread about Tim's

      [20] http://lists.w3.org/Archives/Member/tag/2008Aug/0067.html

    Yves will scribe this afternoon

    ADJOURNED until after lunch.

    <ht> [Member-only link above, sorry]

    <Yves> scribenick: Yves

    <scribe> scribe: Yves

Domain name persistence (workshop planning)

    (round of introductions)

    Helen Hockx-Yu & Kevin Ashley

    ht: commonly raised issue about using http URIs for persistence is
    because of possibilities of 404.
    ... persistence for multi hundred of years, how (owned) domain names
    could achieve such persistence?
    ... might lead to a workshop on digital data persistence.
    ... there are two main lines, first one is to go to IANA for new
    TLDs under new rules that deserve to live forever
    ... leading to more stable reference than with usual domain names
    ... alternate way is to allow existing domains to fall in that
    category of "persistent domain"
    ... open question, what would be the basis for selecting/allowing
    specific domains to become persistent
    ... also some legal issues relative to endowments

    jar: question about attaching metadata to a document, more difficult
    to do in an archive system than on a regular web site
    ... advocates for URN claiming it was more reliable, how to you
    solve the URN resolving issue?

    Kevin: difference between persistent of content, and persistence of
    domain name

    jar: there are three aspects, the data, the cataloguing aspect, the
    metadata, and how to access them
    ... persistence, cataloguing are almost solved problems, but
    automatic retrieval and update of metadata in archived records is an
    unsolved issue

    Helen: we start with seeds URI and crawls. We did two domain crawls
    (of .uk). between the 2 crawls, more than 5% became unavailable, and
    new ones emerged. Also ownership changed on some domains, with
    different content.

    timbl: how many domains have meaningful whois information?

    Helen: the goal is not to detect who the owner is, but that it
    ... memento project is to embed time and date dimension in http
    requests, allowing you to do conneg based on time
    ... you can link to dated version, and the memento server would
    serve the closest in time dated version of the content
    ... there is a plugin for firefox that adds a time slider.

    timbl: so you need to add in your server a link to the memento
    server of your choice
    ... difficulty at W3C to mementoify our content is because ACLs are
    not versioned in time, so you can get content at a specific time,
    but not the list of who was able to access this data

    Kevin: same issue with government material

    ht: there are some examples of useful software where the free
    version of it is only accessible through the wayback machine

    Helen: in our case, we store things in archival format, so when
    people request archived copy, they may not be able to access the


    ht: there are different requirements. in the IETF or W3C case,
    "follow your nose" means that when you get an http exchange, you can
    follow blindy the set of rules, so everything you need to know is on
    the web. But it all depends on http URI resolving.
    ... having the bits available in an archived site is good, but
    having the /TR/ and RFCs available at their URIs is crucial

    <Zakim> ht, you wanted to mention the meeting last Friday, and next

    <noah> TAG Finding on linking to alternate formats:

      [21] http://www.w3.org/2001/tag/doc/alternatives-discovery.html

    ht: trade off between conneg and linkable versions. If you have
    multiple versions, it is good practise to have URIs of the specific
    versions, and a way to list and compare alternates

    Helen: because of technology limitation archived content is not an
    100% faithful copy of a website (because of active content), also
    lots of producers don't want theit content archived

    <ht> So, kinds of reference preservation goals. . . in archives, for
    web standards (follow your nose), [what else]

    Helen: like making accessible things that were removed on purpose
    (like for legal reasons) on one site

    <Zakim> jar, you wanted to suggest 'persistent linking'

    <ht> and "interarchival reference" to the list above

    <noah> Should we start thinking about the workshop?

    <ht> UNESCO ICA -- International Council xxx Archives

    ht: archival task is a bit similar to search engines to avoid
    tarpits (automatic crawling)
    ... jar's issue is persistent linking and not persistent content
    ... need to find a direction

    <ht> ISO group forming wrt Web (archive) Metrics, says Helen H-Y

    (discussions on who would be interested in participating in a
    workshop on persistence)

    <ht> Possible attendees: DNS people (Ask TLR?), Memento designer
    (Herbert van de Sompel), Internet Archive (wayback)

    <ht> (different) National Library people

    <ht> Ray Denenberg, Stu Weibel

    <ht> JR's question: Which intervention point(s) are the most

    <ht> Australian National Data Service; IIPC (International Internet
    Preservation Consortium), Int'l library of Singapore (mtg at IPRES,
    Vienna, September), then IIPC next May in NL

    <jar> I prodded the TAG on Memenot in December:

      [22] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0109.html

    <ht> , National Library of Scotland, IIPC

    <noah> Henry lists things to do moving forward:

    <jar> IIPC = [23]http://netpreserve.org/about/index.php

      [23] http://netpreserve.org/about/index.php

    ht: need a white paper to document the different use cases and
    scenarios, so that we can point possible invitees to

    <noah> Is the whitepaper input to or prepared with output from the
    proposed workshop?

    white paper as a way to ground the discussion on agreed and
    understood points

Web Applications: Client-side state

    <noah> ACTION-430?

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

    <trackbot> [24]http://www.w3.org/2001/tag/group/track/actions/430

      [24] http://www.w3.org/2001/tag/group/track/actions/430


      [25] http://www.w3.org/2001/tag/2010/05/WebApps.html

    <johnk> hello, this is John - is it OK for me to dial in?

    <noah> Yes, great JK. We'll figure out the phone here and dial in

    <johnk> thanks

    <johnk> yes, when my phone boots up ;)

    [discussion moving to security because of John's arrival]

Web Applications: Security

    <noah> [26]http://www.w3.org/2001/tag/tag-weekly#WebAppsSec

      [26] http://www.w3.org/2001/tag/tag-weekly#WebAppsSec

    <noah> [27]http://www.w3.org/2001/tag/2010/06/01-cross-domain.html

      [27] http://www.w3.org/2001/tag/2010/06/01-cross-domain.html

    <noah> ACTION-240?

    <trackbot> ACTION-240 -- John Kemp to read thread on RDFa, CURIEs
    and profile and summarize
    [28]http://lists.w3.org/Archives/Public/www-tag/2009Feb/0295.html --
    due 2009-03-21 -- CLOSED

      [28] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0295.html

    <trackbot> [29]http://www.w3.org/2001/tag/group/track/actions/240

      [29] http://www.w3.org/2001/tag/group/track/actions/240

    <noah> ACTION-340?

    <trackbot> ACTION-340 -- John Kemp to summarize recent discussion
    around XHR and UMP -- due 2010-06-04 -- PENDINGREVIEW

    <trackbot> [30]http://www.w3.org/2001/tag/group/track/actions/340

      [30] http://www.w3.org/2001/tag/group/track/actions/340


      [31] http://www.w3.org/2001/tag/2010/06/01-cross-domain.html

    JohnK: document updated after email feedback from the original TAG
    email on the topic
    ... it is clear that no specification completely forbid to leak
    information form one site to the other (cross-origin forgeries)

    Tim: is it because it is not about all URIs and methods for
    retrieving them (like script, or <img> tags)?

    jar: it is considered safe to load an image or script, not sending

    <jar> *loading* script is ok... it's honoring the script's requests
    that's troublesome

    ashok: if you want websites to cooperate, same origin policy will
    forbid that. cors will help that while still allowing same origin
    policy checks
    ... does cors provide solution to xsrf/clickjacking? => not

    johnK: validating origin alone is not enough to decide to do the
    request or not

    timbl: origin is the origin of the script, the main question is how
    to run script form an untrusted website

    Noah: I sign on an airline site, get a cookie from that site. I
    visit another site that wants to cancel my flight (attack script).
    it starts with a GET request. With CORS, the cookie will go out,
    potentially authenticating me, it will have extra header
    ... for the browser to hand or not the data to the script if it is
    from the authorized list
    ... now, what if it is a POST (or any unsafe operation)

    JohnK: for any unsafe operation there is a 'pre-flight' request



    <jar> DBAD = don't be a deputy



    jar: if you reuse credentials, there will always be [potential for]
    confused deputy attacks

    Noah: surprising in the GET case that instead of having the server
    not returning the data if not allowed, it sends back data and trust
    the user-agent to do the security check on its behalf

    <johnk> dka: that link is also to CORS - (see the link below the
    title to /cors)

    <DKA> oops :)

    <DKA> I meant: [34]http://www.w3.org/TR/widgets-access/

      [34] http://www.w3.org/TR/widgets-access/

    jar: when you authenticate yourself, you give information to your

    ht: in a capability oriented system, there are URIs that allows to
    identify compound resources that are resources+locks

    <johnk> a capability URI is not only a pointer to a resource, but
    the ability to use it

    <johnk> ... do something to that resource

    Noah: is there an guessability of capability URI?

    jar: not if you don't have the credentials to use that capability
    [that must be garbled]
    ... protection against CSRF is about unguessable tokens, in the URI
    or not

    ht: unguessable, but it is interceptable?

    jar: in banks, they also use defense against interception

    <johnk> CSRF prevention example (from my Google account register
    domain HTML form):

    <johnk> <input type="hidden" name="secTok" id="secTok"

    <johnk> value='a06972ccb723db43c20d95985e5f17c5'/>

    (about U:)

      [35] http://www.w3.org/TR/UMP/#access-control-allow-origin-header


      [36] http://www.w3.org/TR/UMP/#access-control-allow-origin-header

    <jar> oauth vs. capabilities:

      [38] http://www.eros-os.org/pipermail/cap-talk/2010-June/014235.html

    <jar> Why we're talking about this (1) the finding that could be
    read as no secrets in URIs, (2) web app security in general

    <noah> Explaining a bit about OAuth vs. CORS/UMP might be
    worthwhile, but I'm a little reluctant to get into doing an analysis
    of the whole server-side vs. client-side data integration tradeoff.

    <johnk> ok

    <jar> timbl: Do we accept the idea that origins can be principals?

    <jar> timbl: Consider a company that provides scripts, and is
    generally trusted to do so

    timbl: using domains as principals means that you trust the script
    to do the right thing, be an intermediary, respect the access

    <jar> timbl: Hypothesis: using domains as principals counts, and
    means something... that you trust the scripts to do the right thing
    ... to be trustworthy intermediaries, to implement some kind of
    access control on behalf of others

    <timbl> So in an ACL-based system, users have to be able to add
    script domains to the ACLs.

    johnk: how do we move forward? broad architectural isue about
    security on the web. The current model is mixing user agent
    authentication and server-based authentication
    ... so security is build on hacks over hacks
    ... the algorithm for user agent is sufficiently complex that is may
    leave holes in the implementation

    <jar> johnk: will ordinary web developers be able to do the right
    thing, or will it be too complex

    johnK: need to have a way to allow web developers to do the right
    thing without having to think too much about it

    ashok: critical to allow people to assess trust, but why is it at
    the header level, and not using policy URIs?

    <Zakim> noah, you wanted to ask about followup & more sessions at
    this F2F

    jar: it has been proposed


    <johnk> ok, I'm going to drop off

    <johnk> please let me know if you have any idea of dates for the
    next meetings

    <johnk> bye!

    <johnk> thanks Yves

Summary of Action Items

    [End of minutes]

     Minutes formatted by David Booth's [39]scribe.perl version 1.135
     ([40]CVS log)
     $Date: 2010/06/15 12:39:36 $

      [39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [40] http://dev.w3.org/cvsweb/2002/scribe/


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

                                - DRAFT -

               Technical Architecture Group Teleconference

08 Jun 2010


       [2] http://www.w3.org/2001/tag/2010/06/07-agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2010/06/08-tagmem-irc


           Dan Appelquist, Tim Berners-Lee, John Kemp (by 'phone, in
           part), Yves Lafon, Ashok Malhotra, Noah Mendelsohn, Jonathan
           Rees, Henry S. Thompson

    John Kemp, Larry Masinter, T. V. Raman
           Noah Mendelsohn

           Dan Appelquist (morning), Henry S. Thompson (afternoon)


      * [4]Topics
          1. [5]Content-type Override (sniffing)
          2. [6]http semantics
          3. [7]Client-side storage
          4. [8]Web Applications: Security

    [agenda discussion]

Content-type Override (sniffing)


    <trackbot> ACTION-370 -- Henry S. Thompson to hST to send a
    revised-as-amended version of
    [9]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html to
    the HTTP bis list on behalf of the TAG -- due 2010-05-17 --

       [9] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html

    <trackbot> [10]http://www.w3.org/2001/tag/group/track/actions/370

      [10] http://www.w3.org/2001/tag/group/track/actions/370

    ht: Yves is one of the editors of the spec. He has suggested putting
    our requested text into another section (of HTTP bis).

    Yves: We have discussed with Mark. He has suggested [and it was the
    consensus in HTTP bis] that it should be in the security section.

    ht: I think it's the best compromise.



    <noah> We are reviewing the above email, which has suggested
    amendments to the TAG's proposed HTTPbis text on sniffing.

    ht: [comparing yves's version to henry's version]

    ht: this is better than the status quo.
    ... the thing that has been taken out is the idea that you shouldn't
    do any kind of media type change unless you have evidence to support
    the belief that the media type is mistaken.

    noah: [points to "risks of sniffing" proposed text in
    ... text "type of the actual document" doesn't [scan]. If you have
    an XML document, it is also text/plain in some sense but if you
    server it as XML then you are signalling that [the receiver] should
    process as XML.


    ht: I feel that 7.3 [Media Type Issue] in Yves's message is a
    reasonable compromise.
    ... My feeling is that - I would be happy if we closed this issue
    with the following email to the [http bis] mailing list - "thank you
    for your response to our suggestion. The prose offered by Yves would
    be a significant improvement. Further changes suggested by Mark
    Nottingham would be [fine] but we're not worried.'

    noah: I'm not so convinced.
    ... I'm not happy with the "may not be that of the actual document"
    text. Also disinclined to close the issue.

    ht: how about a response more like : "thank you for re-opening this
    issue. We think the version suggested by Yves in his message of 24
    March would adequately address our concerns. We're less comfortable
    with the suggested addition in Mark's message of June XX because it
    ... I'm not happy that it goes in the security section because the
    core question is that it overrides user intent but that's a cost I'm
    willing to accept for getting the text in the document at all.

    Noah: this word - "identify" - bothers me. I don't think the
    content-type header identifies.

    ht: Suggest another word.

    Noah: I think it's about the sender's intent. If I send you
    something as [e.g.] PDF, I don't want you to interpret it as

    [some wordsmithing]

    noah: ...correctly convey the intended [type] of the content...

    Yves: it's worth clarifying the text.

    ht: "does not reflect the intended interpretation of the content"

    <noah> Sounds good to me.

    Noah: ok to seek consensus on this?

    Tim: What the TAG often ends up doing is coming up with phrases like
    this that [can only be interpreted] with a background in Web Arch.
    ... I think the new text is fine.

    jar: I wonder what it would be in IETF-jargon?
    ... the core idea in IETF is the stack - e.g. the server
    automatically provides a content type which is not appropriate at
    the application level.

    Noah: we could say "we don't think it's appropriate to say that the
    content type identifies the content" and suggest an alternative.

    ht: quotes chapter and verse

    noah: anyone unhappy?
    ... i think the right concerns have been laid out...
    ... I propose to put down 370... and look at other actions related
    to sniffing.
    ... Larry has written an interesting message in relation to
    ACTION-425. We could go over it...


    <trackbot> ACTION-425 -- Larry Masinter to draft updated MIME
    finding(s), with help from DanA, based on www-tag discussion -- due
    2010-05-31 -- PENDINGREVIEW

    <trackbot> [13]http://www.w3.org/2001/tag/group/track/actions/425

      [13] http://www.w3.org/2001/tag/group/track/actions/425

    Noah: Shall we do ACTION-387 first?

    ht: should we now bring that message up and review it?


    <trackbot> ACTION-387 -- Henry S. Thompson to review JK/NM's stuff
    on sniffing, authoritative metadata, self-describing web, incl.
    [14]http://lists.w3.org/Archives/Public/www-tag/2010Jan/0025.html --
    due 2010-06-07 -- PENDINGREVIEW

      [14] http://lists.w3.org/Archives/Public/www-tag/2010Jan/0025.html

    <trackbot> [15]http://www.w3.org/2001/tag/group/track/actions/387

      [15] http://www.w3.org/2001/tag/group/track/actions/387

    noah: The real context for this - we had a set of discussions. John
    Kemp suggested some updates. I had some concerns... We could leave
    this to this afternoon when John will join us.


    <trackbot> ACTION-425 -- Larry Masinter to draft updated MIME
    finding(s), with help from DanA, based on www-tag discussion -- due
    2010-05-31 -- PENDINGREVIEW

    <trackbot> [16]http://www.w3.org/2001/tag/group/track/actions/425

      [16] http://www.w3.org/2001/tag/group/track/actions/425


      [17] http://masinter.blogspot.com/2010/06/mime-and-web.html


      [18] http://lists.w3.org/Archives/Public/www-tag/2010May/0063.html

    <noah> Mail 0063 is a draft from Larry that we will now review.

    <noah> Yves says
    [19]http://masinter.blogspot.com/2010/06/mime-and-web.html is the
    same text, with better format. We'll review that.

      [19] http://masinter.blogspot.com/2010/06/mime-and-web.html

    Noah: Brings up Larry's blog entry.

    [group reviewing]

    tim: I really like this article.
    ... and I like the fact that he's passionate about cleaning things
    up and has included a list of to-dos. To this is a good role model
    for future TAG things.
    ... now the philosophical rant: there has been some misunderstanding
    in semantic web contexts that the semantics of a fragment identifier
    depend on mime type.
    ... we've been telling people to use a URI name but it also depends
    on the mime type...
    ... so that was the confusion. Both things are true - "this [the
    fragment identifier] is a name" - and when you dereference it the
    MIME type [needs to be consistent].
    ... in the RDF spec says "if you want to know what the triples are
    in this document - this is how you parse them into a set of
    triples." it doesn't say "some of these URIs may include fragment

    jar: You're right that it doesn't say that but the RDF/XML media
    type registration does say that.

    <Yves> [20]http://www.ietf.org/rfc/rfc3870.txt

      [20] http://www.ietf.org/rfc/rfc3870.txt

    jar: you run into trouble if you're using another type - e.g. RDFa.
    So the HTML doc you get back from the FOAF namespace URI, it avoids
    the dual use...

    tim: There are two designs and an "un-design"
    ... design 2: you can have the same ID being used in a way so that
    the human reader when they look at an abstract property they are
    directed to a written description.
    ... design 3: "we know what we mean..."

    ht: second tim's description on 2nd position. There's a sentence on
    RFD-3986 which says "there's content negotiation and this notion
    that the media type defines the semantics of fragment identifies"
    concluding : if you use fragment identifies in context of content
    negotiation it's your job to see to it that the semantics of the
    fragment IDs are not incompatible with each other.

    <noah> [21]http://tools.ietf.org/html/rfc3023#page-16

      [21] http://tools.ietf.org/html/rfc3023#page-16

    noah: I see [a potential problem] in the RDF / XML space.
    ... this is the spec that defines the "+xml" convention.



    [EdNote: We were looking at the above, at least some of us some of
    the time, but the most recent version is
    ml-04.html. It does not appear to differ in the areas under


    noah: +xml convention spec [specifically calls out] fragment
    identification. If you look at that section [in 3023 itself] it says
    "not defined yet." So there is a potential train wreck coming up.

    ht: You're right - this is the definitive statement - but nobody
    pays attention to it.

    tim: What's the solution?

    ht: It's time to look at this again - it's opportune.

    <Yves> [24]http://tools.ietf.org/html/rfc3870#section-3

      [24] http://tools.ietf.org/html/rfc3870#section-3

    Yves: Pointed to fragment identifier section of RDF media type

    Noah: This doesn't resolve anything.

    ht: the particular question on 3023 BIS is - it does not give any

    noah: the problem is that the +xml stuff is tricky.
    ... there is a published rfc-3023 - to which
    ml-03.html#naming is a proposed revision...
    ... I would remove "fragment identification" as something that can
    be [automatically] identified...


    ht: I think - if you write in a media type registration document
    e.g. for SCD+XML - if we define in the W3C spec that defines SCD,
    "fragment identifier semantics is thus and overrides XML
    semantics"... then that's [OK].
    ... you're right - the clear implication of
    ml-03.html#naming as it stands is that if you use the +xml media
    type you are licensing all the interpretations of 3023bis.
    ... the RDF serialisation can do what it does because 3023 is
    under-specified. Once this new version comes out, we've got a real


    noah: I think the spirit is very similar.

    ht: but the letter is different.
    ... quotes: "if [xpointerfranework] and [xpointerelement] are
    inappropriate for some XM-based media types it should not follow the
    naming convention +xml"

    tim: two options: A) remove stuff about frag id, leave rdf+xml; B)
    leave frag ID, remove +xml from rdf

    ht: I had in mind a 3rd way: unlike the other properties, fragment
    identifiers can be overridden in a + spec.
    ... that would still require changing the spec.

    noah: [seeking clarification on (A)]: "remove stuff about frag id as
    part of generic processing"

    tim: Yes.

    noah: I may have written software that doesn't recognize RDF but
    does know the +xml convention. Now that won't work for RDF+XML
    [responding to Henry's 3rd way].

    tim: [names Henry's proposal: "grandfather"]

    ht: fragment identifier interpretation happens...

    tim: In your FOAF file you can use an XSLT -

    jar: If you serve it as rdf+xml it won't work in a browser - you
    have to serve it as .../xml.

    noah: what are our options?

    jar: 4th option: figure out by context what is identified.

    yves: pragmatically that's what implementations will do.
    ... [gives an example involving video]

    tim: That should be in the spec.
    ... We could say "the video tag must only be used for pointing to a
    video and all video mimetypes must use media fragments mime types."
    ... if you happen to have scalable video graphics or animated SVG as
    a video then the mime types must support media fragments.
    ... The TAG should change the architecture document to add that

    noah: I'm OK with that.

    yves: [on using the frag id for specifying a part of a video] if the
    time-range is unknown for the media type then it is ignored.

    ht: whatever happened to vertical bar? | server-side fragments?
    ... real question: is this what you said, Jonathan, for the 'pragma'
    option: "it's OK for generic processors to process generically and
    'RDF' processors to process specially."

    jar: [sort of]
    ... so the question is: suppose through con-neg you get 2 completely
    different documents? Then you'd say "that URI is not a good URI
    because we don't know what it's designating."
    ... this is the HTTP semantics problem.

    ht: if you give an XInclude processor an XML document to process and
    it finds xi:include elements with href elements, it will interpret
    the result as an XML document - unless you say not to.
    ... whereas an RDF processor goes the other direction.

    noah: I'm more worried about people who run generic tools on
    documents that are lying around ...

    tim: xinclude - can I say "xinclude something#foo" ?

    ht: yes: [No, corrected later -- XInclude forbids fragids in its
    'href' attrs, and provides a separate way of designating fragments]

    tim: Then this does break.
    ... if you use that to refer to the element tree, in an RDF document
    it doesn't refer to an element tree it refers [to a concept].

    noah: [calls a break] we will pick this up again tomorrow. I propose
    what we do is come back to ACTION-425 when Larry can be with us.
    ACTION-370 we come back to tomorrow. ACTION-387 we come to this

    [back from break]

http semantics

    jar: [presents slides at
    ... problems that I see in these discussions on "what do URIs mean /
    name" etc...
    ... these are the sorts of questions that I'm trying to model or
    ... didn't get as far as I wanted to get.
    ... not trying to "define meaning."
    ... trying to dispel fear and uncertainty around providing metadata
    for resources on the Web.
    ... needs to be grounded [in operational interpretation] but not too
    soon - you do it formally so what you do has broad applicability.
    ... [presents "http semantics landscapes: exchanges" diagram from
    ... this is not a class diagram.
    ... it's a template for diagrams involving instances.
    ... the point is: you can do an ontological account - a scientific
    account - looking at what really happens in an HTTP exchange.
    ... [introducing "exchange variability" diagram] if you want to look
    at patterns -

      [27] http://www.w3.org/2001/tag/2010/06/http-semantics.pdf

    jar: you can have 2 different request messages that contain the same
    URI. They can lead to 3 different response messages... This leads to
    a cascade of events. Eventually you'll have a response. The outcome
    of these 3 exchanges are these 3 different representations.
    ... [e.g. 2 are in PDF and 1 is in HTML]
    ... there are some properties of the representation which are common
    and some which differ.
    ... talking about "properties of exchanges."
    ... subclasses of exchanges: defined by restriction or by inclusion.
    ... in this modelling, we have some basic axioms already emerging -
    e.g. "every exchange has a send request."
    ... which can be expressed in OWL...
    ... even with this minimal theory you can do something interesting -
    e.g. dated URIs used at W3C - a resource with an interesting
    property in that it only has one representation. It is possible to
    model meaning to an extent.

    jar: you could talk about the class of exchanges with this URI -
    class of exchanges with this URI possesses this invariant.
    ... so classes of exchanges talking about invariance on a
    representation, invariance on the exchange, ...
    ... you can also talk about the relation of these exchanges to the
    ... there are ways you can specify classes not just on restrictions
    on individual members - you can say "these particular members" or
    "has been accessed twice" ...
    ... [in response to question by Ashok] the origin is specified as a
    string and a port number... those would be properties of the
    exchange. If you wanted you could have rule - if the exchange was on
    this origin then do this... a restriction.

    Ashok: It would make this more useful [to add rules]...

    jar: you need a good foundation first...
    ... [back to slides - "subclasses of Exchange" slide 2]
    ... some subclasses: empirical / promise / API / constraint

    tim: here we're talking about network protocols and meaning.
    ... there are social protocols - e.g. when somebody lies - in order
    to design something in the real world you need to consider all the
    possible things an "evil" person could do. Some of these cases you
    don't have to worry about.
    ... we need to distinguish between modelling how things are supposed
    to work and what happens when they don't work.

    jar: this gives a start...

    tim: what's interesting to me - what the TAG says is a meta-level
    promise. If "people behave" the TAG will promise that the server
    will never complain that people have accused them of saying
    something they didn't say...

    [brief toilet-roll discussion]

    jar: [back, thankfully, to the slides]
    ... you can say : all the exchanges I've observed are members of the
    following class...

    ht: is the following claim a claim you want to make: 2 exchanges
    that differ in ways which are not captured by these classes are
    actually not different in any interesting way?

    jar: is that a definition of interesting or a consequence of

    ht: definition, I guess.

    tim: [gives example of how ethernet cable gives a promise of
    containing ethernet packets]

    jar: hypotheses - take e.g. dublin core metadata - if you make an
    assertion that something has this dc:title, etc... there are
    different ways to interpret that but one way to interpret is that
    the representation will satisfy those dublin core properties.

    yves: when you have a promise - that somebody made the assumption
    that something will happen - there is a link to time - during this
    time X the promise might change...

    jar: promises might go bad.
    ... the time at which it happened is a property of an exchange.
    ... last subclass of exchange: induced.
    ... if you're a librarian or a scientist, what you're interested in
    talking about is content, data, measurements, ...
    ... e.g. a telescope is an example of an "induced" resource.
    ... [more on induced exchange classes]
    ... maybe for each kind of thing that you want to allow 200
    responses for you state [what happens].

    tim: this is why it's important to model the semantic web stuff.

    jar: the question of "what is an information resource" is a
    rat-hole. The interesting question is what classes of exchange are
    appropriate to this information resource? And if the answer is
    "none" then [maybe?] it's not an information resource.

    ht: what kinds of differences between representations would be
    allowed for representations of the same resource?

    jar: suppose i want a class of "news sites"? I can do that. but if I
    were to do that with something that today provides news but tomorrow
    is frozen in time then tomorrow it wouldn't be news.

    yves: the news site is a good example. If you do a get on
    newssite.com/latestnews then you get back something with a

    ht: brian smith wrote "semantics of clocks" article - [jar] said you
    could say "an internet clock is a good internet clock if the time
    represented by the relevant string in the response is within some
    epsilon of the time of the response." you could say something
    parallel about news sites...

    DKA: Can you define art?

    <ht> Scots law requires that responses to offers of oral contracts
    must be "timeous" for the contract to be binding

    jar: I wanted to touch on validators as a possible application. Web
    architecture validators. A Link http header could be way to
    communicate promises. Even if you're the one making the promise you
    might want to self-monitor with a validator.
    ... [digression] a promise is a speech act and it has parts.
    ... we now have 10 active metadata ontologies - e.g. "on this web
    page there is a mention of this gene" if they use the URI as the
    subject of that statement then they are worried it might change, the
    con-neg might go wrong, etc...
    ... their fear is that they won't be understood.
    ... what is acceptable to this audience now is things like web
    citation - "from this URI I got the following stuff or some stuff
    with these properties at this date..."
    ... the link header might give some assurance - if it says "this is
    stable content" - they would have more assurance to be able to use
    that URI as a subject.

    tim: so "persistence commons"
    ... w3c has a draft persistence policy...

    yves: they don't want to use the URI because it might change...

    ht: there isn't a transparent way to write a URI which is
    recognisably a reference to a published journal article.

    jar: you can say "info:doi/" - [with some caveats]

    ht: [+1 to the idea of a validator]

    noah: wrap for lunch?

    <jar>[A location detection service:

      [28] http://npdoty.name/location/

    [Resume after lunch]

Client-side storage

    AM: [29]http://www.w3.org/2001/tag/2010/05/WebApps.html

      [29] http://www.w3.org/2001/tag/2010/05/WebApps.html

    [AM speaks to the doc't, not scribed]

    <noah> NM: Is this an API spec?

    <noah> [30]http://www.w3.org/TR/2009/WD-webstorage-20091222/

      [30] http://www.w3.org/TR/2009/WD-webstorage-20091222/

    AM: Yes

    NM: In this design, the javascript gets the data and can do what it
    wants, but the browser doesn't do anything automatically (c.f.

    AM: Yes
    ... Name-value pairs

    JR: 1970s-era file system

    AM: Maybe name-value pairs plus indices

    NM: What is index good for that names can't do?

    AM: More like a database

    Google Gears was there

    scribe: with SQL-like access
    ... but not typed
    ... WebSQL was based on [a particular] product

    <DKA> Web SQL: [31]http://dev.w3.org/html5/webdatabase/

      [31] http://dev.w3.org/html5/webdatabase/

    AM: Hasn't progressed because there is only one (proprietary)
    ... But it looks like the indexed API is going ahead
    ... More efficient than simple name-value

    <DKA> The note from the Web SQL spec: This specification has reached
    an impasse: all interested implementors have used the same SQL
    backend (Sqlite), but we need multiple independent implementations
    to proceed along a standardisation path. Until another implementor
    is interested in implementing this spec, the description of the SQL
    dialect has been left as simply a reference to Sqlite, which isn't
    acceptable for a standard. Should you be an implementor interested
    in imp

    <DKA> ... contact the editor so that he can write a specification
    for the dialect, thus allowing this specification to move forward."

    JR: You don't need CORS . . .

    [scribe lost]

    NM: App has javascript from A, tries to get stockquote from B, not
    possible w/o CORS
    ... Same thing applies once we have local storage -- JS from A wants
    stored information originating from B

    TBL: Suppose we had a consistent access-control ontology
    ... with people, and sites, and origins
    ... and reconstruct something similar to CORS, but more general

    <DKA> [32]http://dev.w3.org/html5/webstorage/#privacy seems
    problematic to me - full of MAY clauses...

      [32] http://dev.w3.org/html5/webstorage/#privacy

    <timbl> yes.

    <timbl> "User agents may, if so configured by the user,
    automatically delete stored data after a period of time." or
    configure by the (eg) bank.

    AM: Agreed

    NM: How do we follow up on this?

    AM: It's possible that the 'may' is opening the door for something
    like CORS

    <timbl> "User agents may allow sites to access session storage areas
    in an unrestricted manner, but require the user to authorize access
    to local storage areas." -- that is the user expressing trust in a
    set of code - that is equivalent to software instalation

    DKA: [Eudora example]

    TBL: You have a local IMAP cache
    ... some clients expose the cache in IMAP format

    NM: what about a better GMail searcher, which would need special
    permissions to get at the GMail cache

    TBL: Facebook is using web storage, and LinkedIn offers better
    functionality if you allow it in

    DKA: I want to build that using OAuth

    NM: But it won't work offline

    DKA: Yes it will, it will keep working on my behalf [between the
    two, w/o my participation]

    TBL: That's going all the way down the road to trusting big services
    ... I'd like to be able to run my IMAP client offline

    DKA: But now a polluted website can inject a script which can
    harvest my email

    TBL: There's no such thing as a little bit trusting

    NM: Distribution is a complex issue
    ... This whole thing also breaks down because the storage stuff
    isn't integrated into our access model
    ... Compare this to the way caches work
    ... where we do have names
    ... The web storage model has no names in that sense, and no
    ... So the existing access control mechanisms may well not

    DKA: Always assumed this was just an optimization

    JR: These things always start small and market forces drive towards
    more functionality

    <timbl> Possible recommenders of trust in scrupts: 1) The user 2)
    The writer of another script (which created some data) 3) a third
    party registry like the addons.mozilla.org or iTunes AppStore

    HST: I had the experience of using earlier versions of some of this
    ... and it was all same-origin protected -- every access had a
    URI-prefix which was SO checked and which constrained subsequent

    HST: Looking briefly at the WD-webstorage-20091222, that appears to
    be still true
    ... The session store vs. local store difference matters
    ... Not clear exactly what patterns of access are allowed . . .

    YL: This is all similar to what happens wrt information in local
    HTTP cache -- the browsers know where data comes from, even if it
    comes from cache

    <timbl> Yves discusses provenance tracking at the javascript
    language level

    YL: So you could require annotation of data with its origin

    JR: But this will still be vulnerable to CSRF

    TBL: A lot of semweb are going in the direction of annotation of all
    triples with provenence info -- triples are becoming quads
    ... And feeding into reason maintenance systems so conclusions can
    be quickly withdrawn if premises are compromised

    ACTION Ashok to comment to web storage guys: basically all of this
    is origin-based, but section 6.1 has a 'may' -- is this a door being
    held open for CORS?

    <trackbot> Created ACTION-438 - Comment to web storage guys:
    basically all of this is origin-based, but section 6.1 has a 'may'
    -- is this a door being held open for CORS? [on Ashok Malhotra - due

    NM: Concerned we need a plan of how to feed this into our overall
    WebApps story

    AM: Work towards some bullet points?

    TBL: Propose "Storage structure and access control should be
    considered separately"

    <Zakim> timbl, you wanted to ask JAR what easier way of doing this

    TBL: JR, how do we do this?

    JR: How do we avoid confused deputy attacked? Where a deputy gets
    too much power, and does more than it was intended to be allowed to

    <noah> The chair infers that the group would like to continue
    technical discussion.

    JR: The way to do this is to pull the authorization as far forward
    as possible, by recording who/what/when is authorized
    ... instead of saying there was a point at which they were
    authorized to do everything

    TBL: You have to have a way of specifying what is allowed -- is that

    JR: Could be

    TBL: Two ways -- characteristic function, or name, for what they are
    going to do, in order to authorize up front

    JR: You have a description of what they want to do, it's to call
    some function with some args
    ... The pblm with CORS is that it just controls access to particular
    API, as it were
    ... Whereas e.g. with Kerberos the authorization act includes what
    it is you can do with the authorization
    ... Whereas with a login-based mechanism, you get authorization to
    "be" a particular user, and all kinds of things come from that

    [scribe missed a bit]

    <timbl> jar: This (login is much too high granularity

    JR: In Javascript this is easy, the auth. decision is an object,
    which encapsulates the capability to do the action . . .

    JR: Adam Barth says this isn't yet viable, because it depends on
    secure ECMAScript, but there's a lot of ordinary Javascript still

    AM: Who are we aiming this at?

    NM: As per WebArch, not the authors of HTTP, but the smart user
    population looking for guidance as to how to use it
    ... So to describe a stable architecture which shows how the specs
    fit together
    ... Which may as a by-product help the authors of the specs that are
    still under construction

    <jar> Adam has done some cool work making origin-based authorization
    decisions work as well as they can in javascript

    AM: I had started with the understanding that there were two goals:
    session storage and persistent storage. Now I see we need to add a
    third: [controlled] cross-site access.

    JR: What's needed is a narrative, not a design

    DKA: Possible kinds of actions: We could try to intervene in the
    progress of the Web Storage spec. What kind of proposal could we
    point them towards?

    NM: Implementations shipped already, or not?

    AM: Not even in last call

    NM: No, I meant the code

    TBL: I'd be surprised if it was baked

    HST: But Mozilla shipped with something close to this at least a
    year ago

    DKA: I will try to find out

    JR: Adam Barth is trying to write an RFC on how to use cookies



    NM: We could say something from the TAG on client-side storage which
    didn't get into the deep security pblms

    <johnk> hi, I'm on the call now

    <noah> Ashok will prepare input to discuss on the telcon on the 17th
    (if we have one)

    <noah> ***BREAK***

Web Applications: Security

    NM: Goal is to have a better idea of whether there's serious writing
    to be done
    ... what next steps if not writing

    AM: If you want sites to cooperate, is CORS/UMP/OAuth/What the way
    to do it?

    NM: What is your opinion, if you have one --- anyone?

    AM: I don't know yet

    JR: Hard to answer, because I've been in the capability camp for so
    ... So if I were designing an app, I would take whatever mechanism I
    could find that would let me layer capabilities on top

    NM: But the web community is going to make a call. . .

    JR: I don't think CORS will scale

    NM: What about UMP?

    JR: Yes, I think it has the right properties -- from an engineering

    <johnk> +1 to Jonathan

    <johnk> agree that UMP is better from architectural perspective

    JR: I see you could need some more structure on top, to match web
    needs . . . there would be a certain amount of re-invention of the
    wheel for the next level, for instance wrt UI

    AM: I still need to think about it, read the specs again

    DKA: I'm more familiar with the CORS approach, I also know OAuth,
    which I think is sometimes the right response
    ... It's a well-used bit of web arch.
    ... I think the widgets digital signature stuff could also be useful
    ... Similar to CORS, but based on signatures, not origin

    NM: How is this an access-control mechanism

    <DKA> [34]http://www.w3.org/TR/widgets-access/

      [34] http://www.w3.org/TR/widgets-access/

    DKA: Here's the spec:

    The doc't is specific to widgets, but it could be extended to docs
    as well

    ACTION Appelquist to introduce signature-based approaches to access

    <trackbot> Created ACTION-439 - Introduce signature-based approaches
    to access control [on Daniel Appelquist - due 2010-06-15].

    YL: I don't think CORS is the ultimate solution to WebApp security
    -- UMP is much simpler. People understand Same Origin, CORS is hard
    to make sense of, where UMP is simpler
    ... It provides what people mostly need, which is cooperation
    between two sites
    ... Much better way in for devs who are not seriously engaged with
    security issues

    HST: So, is Kerberos a capability-based system?

    JR: Like capability, in that you get an unguessable token, but it's
    still a capability just to be a particular person
    ... But it illustrates that the outcome of login can be an object

    <johnk> OAuth is the new Kerberos, roughly-speaking

    <johnk> SAML was the new Kerberos, before OAuth

    HST: So I get that's it's not a clean distinction. . .

    <noah> Possibly pertinent Kerberos RFC

      [35] http://www.ietf.org/rfc/rfc1510.txt

    <noah> Wikipedia simplified description of Kerberos protocol:


    HST:I've recently started using the MarkLogic XQuery + XML datastore
    system. It uses a very fine-grained inventory of permissions, down
    to the individual function level, as well as distinguishing read,
    add and change permissions on the datastore, but it still assigns
    sets of those to user groups, and so depends on user authentication
    == ambient authority

    HST: Having said all that, +1 to finding, articulating and selling a
    capability-based story

    NM: Not sure I have the grounding to make an informed judgement
    ... The concerns I hear about CORS come from impressive sources, and
    I think I hear good things about UMP, as far as it goes
    ... In particular, I don't see how UMP extends to cookie
    functionality, which seems to be what people really need
    ... WRT capabilities, my early experience was not good, so I will
    need to be convinced in practice we can make it work

    <noah> Not quite what I said: capability systems are very cool and
    can work well, but they tend to be somewhat difficult to implement
    and roll out. So, I want to see something that the community will
    accept as practical. Maybe or maybe not something like WebKeys
    signals a direction. I just don't want to gamble on some unseen
    capability system working until we've seen early versions getting
    traction on the Web.

    AM: JR pointed out that Javascript does not have encapsulation --
    without that, how can you do capabilities

    JR: By adding features to the language -- that's what SES (Secure
    ECMAScript) does

    JR: UMP is capabililties at the protocol level, that's not the same
    as capabilities in the programming environment, we need both

    <jar> Too many features -> too much access -> loss of encapsulation.
    Javascript. Remove features -> can't access stuff you shouldn't be
    able to get -> recovery of encapsulation. Secure Javascript.

    JK: Based on experience and reading the specs, I think the
    origin-based approach we have to security today needs to be fixed,
    CORS is not going to do it, and UMP looks like it will
    ... But I also note that the in-practice approach people have taken
    to protecting against CSRF and click-jacking amounts to something
    very close to capabilities in practice

    JK: Fixing origin-based by hacking pseudo-capabilities on top of
    other hacks seems doomed, something cleaner from the ground up
    should be preferred

    <noah> John's framing resonates for me: a key question is whether
    the permission token is integrated with or separate from the
    identifier. The latter approach is, more or less capabilities.

    TBL: Is this a research-grade problem, or is it really ready? The
    extra stuff you, JR, said was needed?

    JR: There is Waterken, which is built on top of UMP using web keys,
    which is a commercial product from Tyler Close

    <jar> [37]http://waterken.sourceforge.net/

      [37] http://waterken.sourceforge.net/

    JR: Note that UMP does not imply Web Key

    <Zakim> jar, you wanted to briefly note that use of UMP does not
    require use of unguessable secret URIs. you can put the CSRF token
    in a parameter i.e. elsewhere in the request e.g. in

    JR: Using UMP for CSRF protection is isomorphic to what people are
    doing today, for example using hidden POST parameters
    ... containing a nonce

    <johnk> yes exactly

    JR: UMP extends this existing story wrt e.g. click-jacking, w/o any
    javascript, into general javascript usage

    ht:I have a PhD studnet, Alex Milowski, who has been looking at
    capability-based security for distributed computation with
    semi-trusted actors. A simplified example is the 'The triangle

    Think of SETI at home... hierarchical decomposition

    suppose a URI names a part of a decomposition of a probem

    Diagram description: Henry shows a central coordination node sending
    http interactions to a farm of worker nodes.

    ht: but the GET has to be done asynchronously, the results may take
    days or weeks to compute.

    <noah> He described it as peer-to-peer, but the diagram is a
    one-level tree.

    ht: triangle architecture: I will give URI to each work for use in
    delivering answer, as well as the question
    ... so I have an S3 account... I want you to do a computation... and
    put the answer there (on my nickel)

    OAUTH doesn't work here. Too much authority granted

    timbl: OAUTH is designed to do that

    noah: SAML too?

    ht: we're just starting to understand the options here

    <noah> SAML = Security assertions markup language

    ht: so we want a capability to store the result. time, location and
    scale limited.

    <noah> Not sure, but XACML may be pertinent too (see:
    [38]http://www.oasis-open.org/committees/xacml/ )

      [38] http://www.oasis-open.org/committees/xacml/

    <noah> Wikipedia on XACML [39]http://en.wikipedia.org/wiki/XACML

      [39] http://en.wikipedia.org/wiki/XACML

    ht: We know S3 doesn't have this ability today, but we can build a
    gateway to S3 that does...
    ... Capability seems the simplest way to talk about this.

    noah: I'd recommend you look at ACL-based approaches

    AM: I don't thing XACML is capability-like
    ... I think it's about access control

    NM: I think it's a bit more fine-grained. . .

    DKA: What's also relevant is that we have browser and server as
    ... which makes me look to OAuth, rather than XACML which would set
    a very high bar

    <johnk> XACML is a language for representing access control policies

    <johnk> SAML is a language for making assertions about a "security

    NM: I find the Web Services approach awkward, but it is driven by
    use cases similar to the one just offered
    ... such as long response times

    JR: We're not in an either-or situation altogether -- based on
    time-scale, for example, capabilities are designed for time-bounded,
    seconds, days or weeks, whereas ACLs are more 'permanent'

    TBL: Capabilities have completely different properties depending on
    whether they can be copied or faked

    JR: If you're cooperating over a secure connection, no third party
    can get the capability

    HST: But you don't necessarily trust the person you send the
    capability to
    ... E.g. in the triangle architecture

    TBL: You may assume everyone is reliably identified, so you can
    grant a capability only to me

    JR: Signing things is only necessary if they can be interpreted

    <jar> HT's example is interesting because it's ok if the capability
    is leaked. doesn't protect anything that matters much

    <Zakim> noah, you wanted to talk about tokens integrated with or not
    integrated with the identifier

    TBL: MiM could get the capability and immediately use it

    HST: Not if the real actor's public key was in the capability

    JR: Or if the connection is encrypted

    NM: JK said something really interesting: comparing a token in a
    POST header with a capability expressed in a URI
    ... but slightly different, in that the coupling between the
    identifier and the capability is different, not by much, but
    ... which reminded me of my concerns about web key
    ... Since a link is a capability, I have to be careful to send my
    URIs carefully, i.e. using HTTPS
    ... But we've also added a post facto requirement for people to
    protect their caches, logs, ....
    ... Maybe there's existing advice which forestalls this, but it runs
    against part of our story about making the Web work: share links,
    ... Makes me nervous to be sure we've spotted all the places that
    have to be secured to guarantee that URI-embedded capabilities can't

    JR: Just remember that UMP isn't committed to web key

    NM: yes, understood

    JR: There's always a credential -- it's got to be communicated, and
    it has to be protected
    ... currently, it's distributed among cookies, ssl keys, IP
    ... It's always in the response
    ... And that's not going to change

    NM: Yes, but my comment was that putting the secret in URIs entrains
    a huge history of what browsers and other tools do with URIs
    ... and that history is very different in impact from the parallel
    history wrt e.g. cookies

    JR: It's a question of what Javascript you write.

    NM: I thought there was a crucial difference between UMP and
    XMLHttpRequest wrt cookies -- XMLHttpRequest automatically attaches
    my cookies for site X to any request to site X
    ... UMP doesn't

    HT: If I do use URI-encoded capabilities, and do what I described in
    my example, with a GET over HTTPs, but my Apache server logs every
    URI, the log file, albeit restricted to root, contains the
    capability and goes to all my sysadmins. I don't want that.

    JAR: Yes, if not used with something else like a login.

    <noah> [40]http://www.w3.org/2001/tag/tag-weekly#WebAppsSec

      [40] http://www.w3.org/2001/tag/tag-weekly#WebAppsSec

    HST: So NM's point is simply that expectations about for example
    privacy vary wrt existing bits of Web Arch, e.g. URI vs. header

    JR: Right. Nothing to do with UMP?

    NM: Right.
    ... JK, what about ACTION-340?

    JK: I think that's done

    <noah> ACTION-340?

    <trackbot> ACTION-340 -- John Kemp to summarize recent discussion
    around XHR and UMP -- due 2010-06-04 -- PENDINGREVIEW

    <trackbot> [41]http://www.w3.org/2001/tag/group/track/actions/340

      [41] http://www.w3.org/2001/tag/group/track/actions/340

    <noah> close ACTION-340

    <trackbot> ACTION-340 summarize recent discussion around XHR and UMP

    <noah> ACTION-417 Due 2010-07-13

    <trackbot> ACTION-417 Frame section 7, security due date now

    <noah> ACTION-435?

    <trackbot> ACTION-435 -- Jonathan Rees to consult Tyler Close
    regarding UMP-informed web storage vulnerability analysis -- due
    2010-06-15 -- OPEN

    <trackbot> [42]http://www.w3.org/2001/tag/group/track/actions/435

      [42] http://www.w3.org/2001/tag/group/track/actions/435

    <noah> ACTION-435 has been bumped to 15 June

    <noah> ACTION-280?

    <trackbot> ACTION-280 -- John Kemp to (with John K) to enumerate
    some CSRF scenarios discussed in Jun in Cambridge -- due 2010-07-06
    -- OPEN

    <trackbot> [43]http://www.w3.org/2001/tag/group/track/actions/280

      [43] http://www.w3.org/2001/tag/group/track/actions/280

    <noah> We just moved ACTION-280 from Dan to John, and made date in
    early July.

    ACTION-33 due 2010-07-15

    <trackbot> ACTION-33 revise naming challenges story in response to
    Dec 2008 F2F discussion due date now 2010-07-15

    <noah> ACTION-344?

    <trackbot> ACTION-344 -- Jonathan Rees to alert TAG chair when CORS
    and/or UMP goes to LC -- due 2010-06-10 -- OPEN

    <trackbot> [44]http://www.w3.org/2001/tag/group/track/actions/344

      [44] http://www.w3.org/2001/tag/group/track/actions/344

    <noah> JAR: I want text of action to record why I'm doing this. I
    think it's so we can do a review of their Last Call regarding
    security considerations.

    <noah> close ACTION-412

    <trackbot> ACTION-412 Try the clarification question, blog item, or
    wiki approach to metadata-in-uris vs CSRF closed

     Minutes formatted by David Booth's [45]scribe.perl version 1.134
     ([46]CVS log)
     $Date: 2010/06/10 09:50:51 $

      [45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [46] http://dev.w3.org/cvsweb/2002/scribe/


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

        Technical Architecture Group - f2f minutes - 9 June 2009

09 Jun 2010

    See also: [2]Agenda, [3]IRC log

       [2] http://www.w3.org/2001/tag/2010/06/07-agenda
       [3] http://www.w3.org/2010/06/09-tagmem-irc


           Henry Thompson, Noah Mendelsohn, Jonathan Rees, Ashok
           Malhotra, Dan Appelquist, Tim Berners-Lee, Yves Lafon

           Larry Masinter, John Kemp, T. V. Raman

           Noah Mendelsohn

           Dan Appelquist, Ashok Malhotra


      * [4]Topics
          1. [5]HTML / XML Unification
          2. [6]Content-type override (ACTION-370 revisited)
          3. [7]Fragment ID semantics and XML Media types (continued)
          4. [8]Web Applications: Identification and URIs
          5. [9]Review Pending Actions
          6. [10]Overdue actions
      * [11]Summary of Action Items

    <trackbot> Date: 09 June 2010

    <DKA> ScribeNick: DKA

HTML / XML Unification

    Noah: [going back to our discussion yesterday on RFC-3023.]
    ... What is the follow-up / action?

    Yves: I can do it.

    Tim: The "grandfathering" option [wasn't a good one]. It's possible
    we can eliminate one of the other options.

    Yves: Should we contact Chris? Nail down what the issue is first?

    Noah: To be picked later at 11:15.
    ... We had a discussion on day 1 on HTML-XML reunification. Let's
    come back to it.

    <Yves> (for the minutes, yesterday's white board
    [12]http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg )

      [12] http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg


      [13] http://lists.w3.org/Archives/Member/tag/2010Jun/0011.html

    ht: this is in reference to HTML wg issue 41.

    <noah> ACTION-427?

    <trackbot> ACTION-427 -- John Kemp to read 4 distributed
    extensibility proposals and summarize them w.r.t. proposals TAG has
    discussed to date -- due 2010-06-06 -- OPEN

    <trackbot> [14]http://www.w3.org/2001/tag/group/track/actions/427

      [14] http://www.w3.org/2001/tag/group/track/actions/427

    ht: interesting thread - subject "facebook have started facebook
    namespace declaration to connect web pages to facebook"
    ... the assertion is that there are thousands to millions of html
    pages with namespace declarations in them (other than the XHTML

    noah: David R from Facebook presented on this at WWW. Said: we don't
    think people will get namespaces right.
    ... also, this is in service to RDFa. So resolution to Qnames isn't

    tim: so facebook are using RDFa.

    ht: with the binding for the curie.
    ... what's crucial is that the namespace binding be in the DOM.

    tim: for people doing interesting things with RDFa in scripts it's
    important. for Facebook maybe not.

    ht: there seems to be a fair consensus that what this points towards
    - what we need is to ensure that these namespace bindings are in the
    DOM - therefore they're available for the parser element names and
    attribute names (and for javascript to do the same)

    tim: actually - james clark's [XML parser] strips the namespace
    bindings out.

    <ht> HST contests TBL's assertion

    ht: it illuminates sentiment in the [html] working group. There's a
    sense of "don't break the Web" - now there are all these pages that
    are using namespace bindings. That's relevant info for discussion of
    [html] issue 41.

    noah: how is that going past www2010?

    ht: hasn't come back up again. not currently on the front burner.
    ... the fact that Facebook did their design the way they did is


    <trackbot> ACTION-427 -- John Kemp to read 4 distributed
    extensibility proposals and summarize them w.r.t. proposals TAG has
    discussed to date -- due 2010-06-06 -- OPEN

    <trackbot> [15]http://www.w3.org/2001/tag/group/track/actions/427

      [15] http://www.w3.org/2001/tag/group/track/actions/427

    ht: html wg issue 41 is open - not currently being discussed. we
    could take the initiative and put forward our preferred proposal.
    ... the most committed pushback from HTML wg is in the area of the
    DOM API.
    ... it comes back to polyglot documents - ref HTML authoring
    guidelines draft of 27 may 2010.

    <noah> HTML Working Group draft on HTML/XHTML Compatibility
    Authoring Guidelines



    ht: is there a succinct discussion of what the XML spec requires of
    a conformant XML processor and what the HTML spec requires of an
    XML-mode processor?
    ... seems this spec does call for a conformant XML parser. So it's
    behaving like what the XML spec calls an application.

    noah: intent [of this document] is to talk about XML as
    conventionally processed. it's about writing HTML which is
    processable as XML.

    yves: if you have an SVG tag in the DOM do you have the namespace?

    tim: when SVG is parsed it's given the SVG namespace int he DOM.

    <noah> I like the document a lot. I can't necessarily say that the
    details are right, but the tone and structure seems to me to be very
    effective, and I assume most of the details are right.



    [Discussion on what this means...]

    <scribe> ACTION: Henry to ask Hixie what is meant in this [section
    9.2] by "retrieving an external entity" and could some clarification
    be added. [recorded in

      [18] http://www.w3.org/2010/06/09-tagmem-minutes.html#action01

    <trackbot> Created ACTION-440 - Ask Hixie what is meant in this
    [section 9.2] by "retrieving an external entity" and could some
    clarification be added. [on Henry S. Thompson - due 2010-06-16].

    <noah> We took a few minutes to unravel the data: URI in section 9.2
    of the HTML 5 draft and verified that it encodes entity definitions
    of the form:

    <noah> <!ENTITY Tab "&#x9;">

    <noah> <!ENTITY NewLine "&#xA;">

    <noah> <!ENTITY excl "&#x21;">

    <noah> <!ENTITY quot "&#x22;">

    <noah> <!ENTITY QUOT "&#x22;">

    ht: we need to get clear just how close the DOMs are - suppose I
    follow the polyglot recommendation. Is it really true that the DOMs
    are the same regardless of which way it gets processed?

    noah: there are 3 styles of DOM we might be concerned with. the XML
    DOM you'd get with Xerxes with no reference to HTML5 spec. At the
    other extreme is the DOM you'd get if you served it as text/html...

    ht: phrase that's in the spec: 2 sets of rules for processing html
    documents: one set for html, one set for xhtml documents.

    noah: potentially there are 3 DOMs... stack of XML spec+ the DOM
    ... are these three distinct in terms of what they build?
    ... I assume that [polyglot spec] is talking about the latter two

    ht: indeed
    ... quotes html5 doc...





    <noah> So, my feeling is there are a few use cases here.

    <noah> The compatibility document correctly points out that one use
    case is to use generic XML tools, and that's indeed important.

    <noah> Nonetheless, when we talk about polyglot, our fundamental
    concern is that there be compatibility when the same bits are served
    >to HTML5 processors< in two diffent modes: 1) as text/html and 2)
    as application/xhtml+xml.

    <noah> It's also nice if the DOMs built by other XML tools are
    similar, but those tools won't do things like scripting, so are
    ultimately a different use case.

    Yves: in html4 there was a difference in expectation (when served as
    HTML or XHTML) about character sets...

    <timbl> Abstract:

    <timbl> A polyglot document is one which is at the same time an XML
    document and an HTML5, and meets well defined set of constraints.
    Polyglot documents are those which use a specific doctype, namespace
    declarations, and a specific case, normally lower case but
    occasionally camel case, for element and attribute names. They use
    lower case for certain attribute values. Further constraints include
    thos eon empty elements, names entity references, and to the use of

    <timbl> style. Polyglot documents meeting these constraints may be
    interpreted equally well as XML or as HTML5.

    ht: [points to special parsing rules for mathml elements]
    ... [and SVG cases]
    ... there is a whole bunch of work done for known names in SVG and
    MATHML namespaces which are camel case. There are specific
    exceptions in HTML5 for this...

    [discussion on how to move forward]

    <timbl> That above is what I think of as an abstract. The text for
    te abstract they have at the moment is a SOTD para

    <timbl> .

    <ht> Turns out it is a parse error in HTML parsing mode if you start
    an element with _anything_ other than a-zA-Z !

    <ht> And case-folding operates all and only on A-Z --> a-z

    jar: what should our internal message be regarding namespaces? What
    seems to be getting lost in arguments is connection between specific
    situations and high-level goals TAG and W3C is trying to promote.
    E.g. self-dscribing Web.
    ... I'm worried about losing track of requirements as we make
    choices about what technical approach to take.

    noah: one thing you didn't mention is distributed extensibility...

    jar: same as "nose-following" story...

    noah: I think there's a fundamental disagreement in the community on
    high-level goals around distributed extensibility.

    jar: I think that is part of the nose-following story...

    noah: when you raise with languages and systems a question of who
    gets to write new specs and who gets to extend them... that's
    ... members of the community have different views of the importance
    of allowing distributed innovation.
    ... if [we] could bring together a group of people who could show
    how [distributed extensibility] can be done that could be useful.

    tim: namespaces and distributed extensibility are linked... [in
    people's minds]

    <ht> Fundamental fact [assertion]: 'the' DOM is a misnomer: A DOM
    instance has to 'know' whether it is an XML DOM or an HTML DOM,
    because the DOM spec. says, wrt string comparisons, that for the
    former name comparison is case-sensitive, while for the latter it is

    jar: even URI based distributed extensibility is based on
    registries, the domain name registry...
    ... what I would like someone to do is what I've been trying to do
    with persistence. Try to lay out and compare all the different
    solutions so we can compare them on criteria whose meaning we agree

    <ht> "Document objects are assumed to be XML documents unless they
    are flagged as being HTML documents when they are created. Whether a
    document is an HTML document or an XML document affects the behavior
    of certain APIs and the case-sensitivity of some selectors."

    [discussion around white board image from December '09 Cambridge
    meeting - table of different proposals...]

    <ht> Should be

      [21] http://www.w3.org/2001/tag/2009/12/10-tagmem-minutes.html

    jar: would like to [frame the question] as "what do you have to do
    in order to extend the language"? Operationally.
    ... we ought to be able to lift up the analysis a level to get more

    ht: practical advantage of this approach is that it doesn't start
    with a discussion of syntax.

    tim: introducing indirect namespace could be a way of decoupling
    these things.

    <noah> Hi Larry, hoping you're feeling better

    <noah> We're about to take a break.

    <masinter> yes, better today

    <masinter> thanks

    <noah> You should know that your media type writeup got a very
    favorable reception, and we're putting off further discussion of it
    until you could join us on a telcon

    <noah> Speaking of which, I will shortly be asking TAG members to
    send hints on which weeks the are/are not/might not be available for
    summer telcons, so if you have a chance to email that it would be

    <noah> Take care.

    +1 to jar's comments on describing things operationally.

    <masinter> great, i was glad it was helpful. I also got some
    positive feedback from Ned Freed, with some suggestions on how to
    move foreward fixing up MIME type registry and other things within

    <noah> Thank you so much for doing it.

    <masinter> and Graham Klyne, who I believe is current MIME
    registration "Expert" reviewer

    <ht> ACTION-437?

    <trackbot> ACTION-437 -- Tim Berners-Lee to create a task force on
    XML / HTML convergence -- due 2010-06-14 -- OPEN

    <trackbot> [22]http://www.w3.org/2001/tag/group/track/actions/437

      [22] http://www.w3.org/2001/tag/group/track/actions/437

    tim: I think [the polyglot spec] should be normative.

    noah: Could someone take an action to draft a response for our
    review? Then tim review.

    tim: it should be written as a subset of documents. it shouldn't be
    called guidelines. like a profile of a language.

    jar: I agree.

    ht: I agree

    noah: I read it and liked it. If I were writing html documents, this
    is what I'd want.
    ... eg it had good guidelines in it - good practical advice.

    tim: in some cases they don't give this information - they don't
    explain why.

    noah: points to notes on use of CDATA in polyglot spec.
    ... yes, you can define a set of documents but the set of documents
    you choose might depend on the outcome - identical DOMs, mostly
    identical, etc...
    ... can anyone take an action to draft a strawman proposal?
    ... We could bring it up in the next telcon.

    tim: we could do it here.

    noah: we could do it in the afternoon.
    ... break for 20 minutes.


    <masinter> hope things are going well, happy birthday Tim

    [we ware back]


    noah: we need consensus of what feedback TAG should give if any on
    the compatibility document.

    <jar> Tim wants a spec that can guide creation of a validator

    noah: the current draft we are reviewing is serving a different
    audience than the document Tim is proposing. You're [Tim] serving an
    audience of what is and what is not a polyglot...
    ... this document [the guidelines doc] is more for content authors.

    tim: I'm addressing the document we have in front of us - it is
    "mathematical" -

    noah: I am also curious for some of these things: this document says
    "if you want something that's completely polyglot then here's your
    rule", "if you want mostly polyglot but differences in the DOM then
    do it this way"
    ... this is signalling to the user that it is a matter of degree.

    jar: tim, you want it to say "if you do x you get the following
    ... this seems doable.
    ... [one issue is] they don't want to make it normative - make it
    into a spec...

    noah: let's move forward. let's try to get some of the technical
    work done here.

    <jar> (the editor *might* say that for some (principled) reason it
    can't be normative...)

    tim: [presents his draft notes]

    [discussion on title]

    noah: how about "XHTML / HTML Compatibility" ?
    ... drop "authoring guidelines"

    jar: We're trying to change it to a spec that can be validated

    [we are live editing Tim's notes]

    <ht> "per the HTML5 specification regardless of whether they are
    processed as HTML or as XHTML"

    <noah> Or "regardless of whether they are processed as HTML or as
    XHTML, per the HTML5 specification "

    <timbl> [23]http://www.w3.org/2010/06/09-polyglot.txt

      [23] http://www.w3.org/2010/06/09-polyglot.txt

    tim: apart from this are there other changes we want to see?

    ht: I'd like to see more script authoring guidelines -
    ... there are ways of accessing the DOM that only work under one
    ... if you look for some elements in your script you might only get
    them if you analyze the document as an HTML document ... [has to do
    with cases of elements and attributes]
    ... We could ask "are there any other aspects of DOM access aside
    from name matching [that need to be spelled out]?"

    noah: would it be worth mentioning the existence of formal MUSTs.

    <jar> How about "2116 language should be used in normative text, and
    not used in

    <jar> nonnormative text. "

    noah: specifically at minimum all the text with formal MUSTs should
    be normative.

    jar: this is a request to the editors

    <jar> I agree, "is" is better than "must"

    tim: we should take the MUSTs out and say "a polyglot document IS

    <noah> I can live with either, slight preference for "is"

    jar: a polite sentence about the desire to have a validator...

    <jar> Something like "We request the editors, in revising this
    document, to keep in mind

    <jar> that we will want to base a validator on the MUSTs given in

    <jar> document."

    <jar> I'm saying that the spec should be helpful to someone
    *writing* a validator - not that we are asking anyone in particular
    to *provide* a validator

    <jar> yves: So JAR is saying: All the MUST- (or is-) level
    requirements must be testable.

    <timbl> [24]http://www.w3.org/2001/tag/2010/06

      [24] http://www.w3.org/2001/tag/2010/06

    <noah> Note that Tim has checked in draft response at

      [25] http://www.w3.org/2001/tag/2010/06/09-polyglot.txt

    jar: I'm talking about validating whether a document is
    syntactically valid according to...

    tim: would only work for the class of documents that don't have

    <jar> my mistake, validating scripts for containment in the polyglot
    subset is untestable.

    noah: the class of documents with scripts that have less-than

    <jar> but other than that...

    tim: that is testable.

    <timbl> In general, whether the scripts "do the right thing" is not

    [discussion on what can and can't be determined programatically]

    ht: I might have another document which has scripts and loads this
    document into an iframe...
    ... why is tbody on this list? it's only because of scripting?

    tim: yes.

    ht: I want a stronger invariant. I want the promise of polyglot
    documents that they produce the same DOM and tbody violates that.

    yves: [but those exceptions / warnings are discussed in the

    noah: 6.1.1 says "a table must have a tbody"

    tim: I agree with what they've done.
    ... I disagree with henry. I'm fine for the tbody to be in there...

    ht: I'm interested to know how big the list of [exceptional cases
    where the DOM is different] is.
    ... e.g. because the HTML5 spec constrains where you get CDATA

    tim: I think one of the nice things about this is that it gives a

    ht: I think [tim and myself] are in violent agreement.

    <jar> (1) class of syntactically valid html docs, (2) class of
    syntactically valid xhtml docs, (3) intersection of (1) and (2), (4)
    subset of (3) for which specified user agent behavior is same, (5)
    subset of (4) for which dom is the same for arbitrary processors ...

    tim: not trying to define the class of every single document ...

    <timbl> This group was asked to go away and define some somewhat
    arbitrary subset of 5

    <jar> my (1)-(5) list is my attempt to list the document classes
    that we've just been discussing... checking my understanding

    noah: do we have consensus from those in the room? If so, should we
    wait for those not in the room?

    <timbl> PROPOSED: To pass [26]http://www.w3.org/2001/tag/2010/06 on
    to the authors as feedback from the people here present.

      [26] http://www.w3.org/2001/tag/2010/06

    ht: [I think we should run with it.]


    <noah> +1

    <Ashok> +1

    <timbl> logger, pointer?

    [discussion on whether we are looking at the right section]

    jar: [we should] just do it.

    <timbl> +1

    <jar> request that Tim add URI for editors draft, with the date on
    which retrieved, to be clear to them what we looked at (CVS 1.14)

    <timbl> Sent

    <Ashok> scribenick: Ashok

    <scribe> scribe: Ashok_Malhotra

Content-type override (ACTION-370 revisited)

    <noah> [27]http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html

      [27] http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html

    ht: Expalins the document
    ... we are happy with the text that Yves proposed
    ... suggests two minor changes
    ... suggests changes to section 3.1.2

    NM: Please mention tag action

    <ht> proposed RESOLUTION: HST to send the contents of
    [28]http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html to
    ietf-http-wg, cced to public-html and www-tag, with minor fixes
    given above

      [28] http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html

    No objections

    RESOLUTION: HST to send the contents of
    [29]http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html to
    ietf-http-wg, cced to public-html and www-tag, with minor fixes
    given above

      [29] http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html

    ht to close action once msg is sent

    issue stays open becuase there is other work on it.

    NM: Will discuss Larry's MIME type document on next telcon

Fragment ID semantics and XML Media types (continued)

    NM: # During our discussion on 8 June, we noticed what appears to be
    a conflict between the fragment ID semantics for media type
    application/rdf+xml, and RFC 3023 as published, and also with
    proposed revisions to RFC 3023 (see also section: A Naming
    Convention for XML-Based Media Types). We agreed to continue the
    discussion on 9 June.

    Tim: Design is which some frag id are 'concepts' and some are
    anchors and you can tell from the context

    The other design the RDF ones are RDF are RDF but others can be used
    as anchors

    Tim: The TAG shd recommend ...
    ... cannot do generic processing of frag ids just on the basis that
    it is XML

    <ht> Close ACTION-370

    <trackbot> ACTION-370 HST to send a revised-as-amended version of
    [30]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html to
    the HTTP bis list on behalf of the TAG closed

      [30] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html

    NM: We shd contact the folks who think you can do generic processing
    and tell them they cannot do generic processing

    <noah> [31]http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg

      [31] http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg

    AM: We are going to recoomend alpha, correct?

    ht: I prefer the pragma' solution ...

    jar: Is there really a conflict in XML Processing?

    NM: I have a case which breaks ... I can write a tool that sees a
    URI with fragId

    <noah> Example:

    <noah> 1) I write a tool that finds a link with fragid

    NM: that sees +XML and use XPointer to navigate thru the doc and I
    am unhappy

    <timbl> PROPOSED: That the text about fragment id semantics should
    be removed from the stuff about generic procesing

    <noah> 1) I write a tool that finds a link with fragid

    <noah> 1) I write a tool that finds a link with fragid

      [32] http://lnk/#somefrag)

    <noah> 2) The tool follows the link, gets back application/rdf+xml.
    Unfortunately, when I wrote the tool, I had not read the spec for
    rdf+xml, but I had read the 3023 and/or 3023 bis specs.

    <jar> you mean you follow [33]http://lnk (you do the relevant GET)

      [33] http://lnk/

    <noah> 3) My tool, believing that 3023 applies, interprets somefrag
    as an xpointer, and infers that the URI (attempts to) reference an
    element named somefrag

    <noah> QED?

    ht: What's wrong?

    NM: He wanted to reference to the element

    HT: Do generic XML processor XML as XML?

    NM: Tool does not have knowledge of the vocabulary

    HT: A generic processor cannot be wrong

    <jar> Here's my example: in [34]http://example.com/w rdf+xml I say
    <foaf:Document id="zzz"> <owl:sameAs
    rdf:resource="[35]http://example.org/x"/> </...> ... then the
    browser (a generci xml tool) follows
    href="[36]http://example.org/w#zzz" - should it (should ie be
    allowed) to go to example.org/x ? or to the rdf:Document element in
    example.org/w ?

      [34] http://example.com/w
      [35] http://example.org/x
      [36] http://example.org/w#zzz

    <DKA> Found an interesting and possibly relevant draft by Mark Baker
    from 2002:


    Tim: Explains example on whiteboard ... interpretations of <FOO
    ... difference between XML tools and RDF tools

    HT: If you had the same triples in a triple store you would have a
    ... but why would you load both in the same triple store?
    ... I don't think the contradiction is the fault of the frag-id

    <Zakim> noah, you wanted to discuss why it's broken

    NM: I'm in the queue to answer HT's question
    ... I described an XML tool ... HT asked what's broken
    ... 3023 encourages sub-media types
    ... encorouging that is broken
    ... I would remove the para fron 3023 that starts "Fragment
    Identification -"



    <Zakim> jar, you wanted to examplify

    <jar> "XPointers (see Section 5) can work with any XML document"

    JAR: Explains his example above ... the tools is now a Web Browser
    ... say HTML4 user agent
    ... media type is RDF+XML
    ... browser has a choice of XML processing or RDF processing and
    will end up with different results

    <jar> It is possible to come up with examples that say that there's
    a problem, but it's hard for me to imagine that there is *currently*
    a problem in any particular case (since all of our examples involve
    hypothetical tools)

    <ht> [39]http://www.w3.org/TR/xinclude/#processing

      [39] http://www.w3.org/TR/xinclude/#processing

    <noah> Probably true, Jonathan, but if you're implying that we can
    leave the architecture "broken" just because no current software
    badly misbehaves, I'm unconvinced.

    <DKA> ScribeNick: DKA

    [discussing 4.2 in xinclude spec]

    henry: you can't use fragment identifiers.

    noah: this is a red herring.

    <timbl> timbl: PROPOSED: That the text about fragment id semantics
    should be removed from the stuff about generic procesing

    noah: [back to proposals] back to proposal a (alpha).

    <timbl> Well, red herring ecept that as Yves points out is demos
    that you really can't use fragids with generic processing.

    ht: one way to get an xpath data model is to point a conformant
    processor at anything.

    noah: web arch says "follow your nose"

    jar: if xpointer is about infosets then what [dan c] said works...

    <scribe> ScribeNick: Ashok

    <Yves> [40]http://www.w3.org/TR/xptr-framework/

      [40] http://www.w3.org/TR/xptr-framework/


      [41] http://www.w3.org/TR/xptr-framework/
      [42] http://www.w3.org/TR/2003/REC-xptr-framework-20030325/

    HT: Says "internal structures of XML Processors"

    <jar> If xpointer is about infosets, then the 'pragma' approach
    makes sense, since there's no ambiguity... if xpointer is about
    resources and 'identification', then the 'alpha' (don't allow
    xpointer on rdf+xml) makes more sense...

    <ht> "A software component that identifies subresources of an XML

    <jar> ht: Two ways to argue from this that the current situation is
    not broken

    HT: from this you could argue that current situation in not broken
    ... ontology is not an XML Resource

    <jar> ht: 1. you could say, it's not an xml resource, it's an

    Tim: You are defining XM Resource ... this would take you a long

    <jar> ht: (didn't get around to saying what 2. was)

    HT: This is pushing me towards solution Beta --- we should not have
    used XML+RDF just RDF

    YL: If we say frag-id processing is not part of general XML
    Processing ... media types tell you what to do

    <Zakim> ht, you wanted to express concern about levels

    YL: warnings about frag-id processing

    <timbl> HT, [43]http://www.w3.org/2007/ont/xml#Node

      [43] http://www.w3.org/2007/ont/xml#Node

    YL: Frag processing should not be part of generic XML processing

    <timbl> is the class of XML node as parsed ... DanC wrote the code
    in 2007

    <timbl> [44]http://www.w3.org/2000/10/swap/cwm_xml.py

      [44] http://www.w3.org/2000/10/swap/cwm_xml.py

    <ht> I am concerned that by losing the notion of generic processing
    as legitimate for at least barename fragids, we are losing real
    value. . .

    NM: I see some support for gamma --- generic processors shd be aware
    of special processing required ...

    <ht> But, question arises, I guess, what is an example of generic
    processing of URIs+fragIDs, given that XInclude is _not_ an example

    NM: Yves wanted an opt-in/opt-out approach

    YL: I'm close to alpha

    HT: I want some time ... I would like help from the XML Core WG

    <noah> . ACTION Noah to draft proposed TAG comment on 3023bis
    regarding fragment ID handling

    <noah> The action is to reflect our so-called option alpha, I.e.
    fragid processing should not be generic, because train has left the
    station on rdf+xml

    <noah> Note will be sent for TAG internal review, with 4 day speak
    or hold peace window.

    <noah> ACTION Noah to draft proposed TAG comment on 3023bis
    regarding fragment ID handling

    <trackbot> Created ACTION-441 - Draft proposed TAG comment on
    3023bis regarding fragment ID handling [on Noah Mendelsohn - due

    NM: We are done with this agenda item.

    <ht> -M 0 -F /etc/autossh/ssh_config -n w3tunnel

    <ht> Host w3tunnel

    <ht> IdentityFile /etc/autossh/id_dsa

    <ht> UserKnownHostsFile /etc/autossh/known_hosts

    <ht> HostName jay.w3.org

    <ht> User ht

    <ht> LocalForward 6667 irc.w3.org:6667

    <jar> cognate

Web Applications: Identification and URIs

    NM: raman wrote a draft on client-side manipulation of URIs
    ... I presented the Google Maps scenario
    ... Raman was assigned ACTION-422 to do that
    ... he wrote something that idid not fulfill the action
    ... I took ACTION-432 to write the Google maps case

    AM: I offer to try and integrate NM and TVR words into a coherent


    <trackbot> ACTION-432 Review client state finding update w.r.t. maps
    case closed


    <trackbot> ACTION-422 Examine the current text of his client state
    finding and update appropriately with Noah's email from ACTION-353

    ACTION Ashok to trya nd integrate NM and TVRs words into a coherent

    <trackbot> Created ACTION-442 - Trya nd integrate NM and TVRs words
    into a coherent draft [on Ashok Malhotra - due 2010-06-16].

    JAR: Are there any issues here?

    NM: TVR wrote a draft describing a specific scenario
    ... he did not want Google Maps case because "everyone knows that".

    jar: Does thic touch on media-type registration?
    ... how do you follow your nose if there is a frag-id?


    <jar> action jar to chase down what specs say regarding looking up
    fragid in 2nd representation if not found in 2st representation

    <trackbot> Created ACTION-443 - Chase down what specs say regarding
    looking up fragid in 2nd representation if not found in 2nd
    representation [on Jonathan Rees - due 2010-06-16].

    <jar> e.g. FOAF

    <jar> related to (not same as) using javascript to 'resolve' fragids

    HT: Question of whether you should be able to conneg between

    <jar> noah: location bar doesn't update as you pan and scroll maps

    HT: side issue on address bar updating
    ... it matters if the URI can leak or not -- say by emailing
    ... if you reload the URI it violates the nedia types spec. I think
    there is an issue here

Review Pending Actions

    ACTION-404 on DanC

    Reassign to Yves to evaluate

    scribe: due June 29

    <jar> (question is whether html agrees to use ietf link relation

    ACTION-409 Reopen with due date of June 29

    <noah> ACTION-433 is overtaken ACTION-437. Closing 433.

    <noah> CLOSE ACTION-433

    <trackbot> ACTION-433 Help Tim get in touch with staff etc. re
    XML/HTML unification closed

Overdue actions

    <noah> ACTION-201?

    <trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW
    discussions -- due 2010-05-29 -- OPEN

    <trackbot> [45]http://www.w3.org/2001/tag/group/track/actions/201

      [45] http://www.w3.org/2001/tag/group/track/actions/201

    <noah> ACTION-201 Due 2010-10-05

    <trackbot> ACTION-201 Report on status of AWWSW discussions due date
    now 2010-10-05

    <noah> ACTION-282?

    <trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
    metadata architecture. -- due 2010-05-31 -- OPEN

    <trackbot> [46]http://www.w3.org/2001/tag/group/track/actions/282

      [46] http://www.w3.org/2001/tag/group/track/actions/282

    <noah> JAR: I'm on the way to proposing that is same as AWWSW work.

    <noah> ACTION-282 Due 2010-10-05

    <trackbot> ACTION-282 Draft a finding on metadata architecture. due
    date now 2010-10-05

    <noah> ACTION-341?

    <trackbot> ACTION-341 -- Dan Connolly to follow up with Thomas about
    security review activities for HTML5 -- due 2010-05-28 -- OPEN

    <trackbot> [47]http://www.w3.org/2001/tag/group/track/actions/341

      [47] http://www.w3.org/2001/tag/group/track/actions/341

    <noah> There is a BOF coming up at IETF for possible new security

    <noah> That's in addition to the W3C effort

    <noah> YL: They'll be including work on WebApps

    <noah> JAR: Maybe we don't need to track it? Those are all good

    <Yves> [48]https://www.ietf.org/mailman/listinfo/hasmat

      [48] https://www.ietf.org/mailman/listinfo/hasmat


      [49] http://www.ietf.org/mail-archive/web/hasmat/current/msg00001.html

    ACTION-341 Resaiigned to Yves due date June 15

    <noah> ACTION-341?

    <trackbot> ACTION-341 -- Yves Lafon to follow up with Thomas about
    security review activities for HTML5 -- due 2010-06-15 -- OPEN

    <trackbot> [50]http://www.w3.org/2001/tag/group/track/actions/341

      [50] http://www.w3.org/2001/tag/group/track/actions/341

    ACTION-368 Jar will send mail to DanC saying you can close 368 if
    you want to.

    <noah> ACTION-379?

    <trackbot> ACTION-379 -- Noah Mendelsohn to check whether HTML
    language reference has been published -- due 2010-03-24 -- OPEN

    <trackbot> [51]http://www.w3.org/2001/tag/group/track/actions/379

      [51] http://www.w3.org/2001/tag/group/track/actions/379

    ACTION-379 NM: There has been interaction. Keep open. Bump date

    <noah> ACTION-379 Due 2010-07-20

    <trackbot> ACTION-379 Check whether HTML language reference has been
    published due date now 2010-07-20

    <DKA> issue-58?

    <trackbot> ISSUE-58 -- Scalability of URI Access to Resources --

    <trackbot> [52]http://www.w3.org/2001/tag/group/track/issues/58

      [52] http://www.w3.org/2001/tag/group/track/issues/58

    ACTION-381 Jar: Push it out 2 weeks

    <noah> ISSUE-58?

    <trackbot> ISSUE-58 -- Scalability of URI Access to Resources --

    <trackbot> [53]http://www.w3.org/2001/tag/group/track/issues/58

      [53] http://www.w3.org/2001/tag/group/track/issues/58

    <noah> ACTION-390?

    <trackbot> ACTION-390 -- Daniel Appelquist to review ISSUE-58 and
    suggest next steps -- due 2010-05-25 -- OPEN

    <trackbot> [54]http://www.w3.org/2001/tag/group/track/actions/390

      [54] http://www.w3.org/2001/tag/group/track/actions/390

    DKA: I have been looking at this.

    <jar> DKA: elastic computing resource

    Tim: Problem is there is a bug in the code

    Dka: There is more ....

    <noah> YL: There are differences between getting the same URIs, vs.
    honoring cache headers, vs. with DTDs we made a decision that
    referent is immutable, but that violates a notion that HTTP headers
    should never expire > 1 years

    <noah> DA: Maybe you partially answered: what do you think the TAG
    can do?

    <noah> DA: One thing to say it's "not nice", but we don't have
    police powers.

    <noah> JAR: To mark a response as "never expires, the response
    server sends a response saying it responds with a date in
    approximately 1 year"?

    <noah> YL: Let's look at the right version

    <Yves> [55]http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-09

      [55] http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-09

    <jar> "HTTP/1.1 servers SHOULD NOT send Expires dates more than one
    year in the future."

    <jar> This sentence was removed going from 2616 to 2616bis: 'To mark
    a response as "never expires," an origin server sends an Expires
    date approximately one year from the time the response is sent.'

    <noah> NM: The problem is, it's really hard to write a normative,
    enforceable spec, that tells you when you MUST retain a
    representation for resuse.

    <noah> NM: Lacking that, this is a hard problem to solve.


Summary of Action Items

    [NEW] ACTION: Henry to ask Hixie what is meant in this [section 9.2]
    by "retrieving an external entity" and could some clarification be
    added. [recorded in

      [56] http://www.w3.org/2010/06/09-tagmem-minutes.html#action01

    [End of minutes]

     Minutes formatted by David Booth's [57]scribe.perl version 1.135
     ([58]CVS log)
     $Date: 2010/06/09 16:09:15 $

      [57] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [58] http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 16 June 2010 18:35:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:34 UTC