Draft minutes of 4-6 January 2012 TAG F2F are now available

Draft minutes of the 4-6 January 2012 TAG F2F are now linked from the 
agenda at [1] and are also provided in text-only form below. Please note 
that these minutes have not yet been reviewed by the TAG and will not be 
considered a formal record of the meeting until approved.

Thank you very much.

Noah

[1] http://www.w3.org/2001/tag/2012/01/04-agenda


================== 4 January 2012 =====================

    [1]W3C

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

                                - DRAFT -

                TAG Face to Face Meeting 04 January 2012

04 Jan 2012

    See also: [2]IRC log

       [2] http://www.w3.org/2012/01/04-tagmem-irc

Attendees

    Present
           Noah Mendelsohn, Jonathan Rees, Peter Linss, Larry Masinter,
           Tim Berners-Lee, Yves Lafon, Dan Appelquist, Jeni Tennison,
           Glenn Adams, Henry Thompson

    Regrets
           none

    Chair
           Noah Mendelsohn

    Scribe
           Yves Lafon, Jeni Tennison, Dan Appelquist

Contents

      * [3]Topics
          1. [4]Review Agenda
          2. [5]Persistent references
          3. [6]MIME and the Web
          4. [7]URI Definition Discovery; Metadata Architecture
          5. [8]Can publication of hyperlinks constitute copyright
             infringement?
      * [9]Summary of Action Items
      _________________________________________________________

Review Agenda

    Noah: First thing is to open the floor so that we can discuss what
    is on the agenda

    one of the question is: do we need to continue to track issues or
    should we track products (like on the product page). We need a
    discussion but f2f time is already filled with technical
    discussions.

    Ashok: are there important things buried in issues that might
    disappear if we move to products

    Yves: how to track not-yet-products, create a new product? use a
    generic product?

    Noah: can be done using actions.
    ... administrative stuff

    please register for scribing slots

    approval of minutes

    <noah> [10]http://www.w3.org/2001/tag/2011/12/22-minutes

      [10] http://www.w3.org/2001/tag/2011/12/22-minutes

    RESOLUTION: minutes above approved

    <noah> [11]http://www.w3.org/2001/tag/products/

      [11] http://www.w3.org/2001/tag/products/

    fragment identifiers & mime type: not scheduled as no progress were
    done

    RESOLUTION: close the Web Application State (pending publication of
    the final Note)

    DKA: wrt API minimization, we should leave it in a better state, but
    no discussion is scheduled

    noah Is API minimization worth doing

    DKA Absolutely

    noahOK, to be considered after the election

    <noah> ACTION: Ashok to draft product page on client-side storage
    focusing on specific goals and success criteria Due: 2012-01-17
    recorded in [12]http://www.w3.org/2012/01/04-tagmem-irc]

      [12] http://www.w3.org/2012/01/04-tagmem-irc

    <trackbot> Created ACTION-647 - Draft product page on client-side
    storage focusing on specific goals and success criteria Due:
    2012-01-17 [on Ashok Malhotra - due 2012-01-11].

    <glenn> possible minor typo under "Completed" table in products
    page: "Completion ... was announced on 30 December 2012"?

    <Yves> indeed

Persistent references

    [13]http://www.w3.org/2001/tag/products/persistence.html

      [13] http://www.w3.org/2001/tag/products/persistence.html

    Noah: main question is "is there anything after the workshop report
    we need to do" ?

    jar: workshop took place on dec 8th in Bristol

    Draft report:
    [14]http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html

      [14] http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html

    we didn't have people saying that it was an impossible goal. No pure
    "cool URI" advocate stating that there was no problem to solve. No
    advocate of archives being sufficient

    we didn't talk about what 'persistence' was

    to me persistence is like trust

    Yves: trusting that it will be persistent, or that the
    representation is trustable (ie: not tampered with)

    jar: there is a gradation of attacks, squatting being a threat to
    persistence, so it's both

    people had a shared intuition of what persistence meant

    registry of media types or link relation is a good example of
    persistence

    even in the case of ISBN, it happened that some numbers were
    recycled, threatening the persistence of the identifier

    There was the idea that in theory, persistent domain names were
    doable. One example is the use of the .arpa system

    This removes possibility to change owner, so create an immutable
    name (or mutable through a review process)

    Larry: .arpa currently only IPV4-related

    <JeniT> [15]http://www.iana.org/domains/arpa

      [15] http://www.iana.org/domains/arpa

    jar: it's just the constituency that is interesting. Like .invalid

    Noah: what is the update bandwidth of .arpa ?

    jar: it's RFC-based; the outcome was not "move everything under
    .arpa"

    options can be register a subdomain, a tld that offers persistence,
    etc...

    noah A little confused: earlier you said there was not great
    interest in a new TLD, but now you're saying .arpa is just an
    existence proof. Isn't it an existence proof for a new TLD?

    jar Not necessarily. What's important is that you've shown that a
    regime like this can be created. Could be realized as new TLD, could
    be realized as new domain under .arpa, or one could retroactively
    gold plate some existing domain(s)

    (discussion about persistence of names vs persistence of
    representations and resolution)

    <noah> Henry, do you need/want time to speak on this? We've got ~30
    mins, but I want to devote the last 15 or so to TAG next steps

    jar: bio names is a good example of a system where noone is
    reponsible for (it works by just publishing the name) but works.

    Tim: but this is not a system under lots of stress, like the dns
    system is

    Noah: there are different communities there, one where this
    'dns-like stress' is irrelevant, and others where it is the default

    Yves: we are shifting from trust in the persistence to provenance
    issues of the representation, those are different
    <ht>
    [16]http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html

      [16] http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html

    <Zakim> ht, you wanted to note that I'm supposed to be reporting
    too!

    <ht> no audio?

    <masinter> (I said): when we do protocol design to design something
    to solve a problem, it's important to identify the scope of what
    problem is being solved, and waht isn't. In this case, we're picking
    at the edges of trust & security because of issues like SOPA
    take-down notices or someone disagreeing about biological names in
    some communities. The report on persistent domains hasn't been clear
    about waht the scope is, and that's why we're picking on it.

    <masinter> jar replied: it was interesting that at the workshop we
    didn't feel a need to discuss scope at length

    <jar> (I said): The scope was relative: We want domain-name-based
    naming that will be perceived as as "persistent" as, say, MIME types
    or ISBNs (persistence standard imported from other domain)? and are
    actionable

    <jar> Gavin Brown of CentralNIC

    ht: the .arpa solution came from nowhere, nobody was expecting it.

    the idea was that gold plated domain named ought to be governed by
    community process.

    <jar> gold-plating needs a community process, IETF is a good example
    of such a process

    the idea was also to use .arpa to create new persistent domains
    (like .doi.arpa)

    <jar> the governing document for .arpa already sets out the
    requirements. only agreement needed would be with IAB - ICANN, IANA
    not in the picture .arpa is different that any other tld, no
    registrar, no contract.

    <noah> Could a new TLD be created with the same characteristic?

    ht: I am not at all sure that the IAB would be happy to create
    something that would look like a real domain under .arpa

    <jar> But expecting resistance from IAB since this would imply lots
    of ordinary DNS traffic through .arpa - a new idea

    the ideal approach would be to have parts of existing domains
    persistents

    <noah> I need to cut this off in 2 mins. We are at time, and need
    10+ minutes on TAG goals.

    <jar> by registering dx.doi.org.arpa, side effect would be to make
    dx.doi.org 'persistent'

    we could use the .arpa to record that dx.doi.org is persistent, but
    not binding resolution to the .arpa domain but leave it to
    dx.doi.org system (ie: normal dns behaviour)

    <masinter> Doesn't ISOC run .org? Maybe just asking ISOC to offer
    some persistence guarantees for organizations that meet some
    persistence criteria?

    <jar> PIR runs .org

    Noah: Henry, do you have an email with what you just talked about?

    <jar> yes, that's a promising option, larry

    <ht>
    [17]http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html

      [17] http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html

    (discussion on the product page)

    <noah> [18]http://www.w3.org/2001/tag/products/persistence.html

      [18] http://www.w3.org/2001/tag/products/persistence.html

    Tim: we need to create a scenario document

    <jar> timbl calls for a TAG document explaining the process we might
    like to see in the future for gold-plating

    <jar> masinter: What doesn't work now that would work better if we
    succeed?

    <masinter> it isn't foolish to try to obtain consensus

    <ht> No, but it's foolish to give me an action to obtain it!

    <masinter> criterial for me is that it be clear to a reader not
    already invested in this, "what will work better, if the TAG does
    this work?"

    <noah> ACTION-528?

    <trackbot> ACTION-528 -- Henry Thompson to create and get consensus
    on a product page and tracker product page for persistence of names
    -- due 2012-01-02 -- OPEN

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

      [19] http://www.w3.org/2001/tag/group/track/actions/528

    <ht> trackbot, ACTION-528 due 2012-01-06

    <trackbot> ACTION-528 Create and get consensus on a product page and
    tracker product page for persistence of names due date now
    2012-01-06

    <masinter> somewhere, at least one of the success criteria has to be
    doing something

    BREAK

MIME and the Web

    slides: [20]http://www.w3.org/2001/tag/2012/01/mimeweb.pdf

      [20] http://www.w3.org/2001/tag/2012/01/mimeweb.pdf

    <noah> FWIW: Larry's use of the term language strikes me as
    sensible, if informal, but it's only vaguely related to the
    carefully negotiated definition the TAG agreed a few years ago

    <noah> I think there's the core of something very good here...

    analogy between mime type and persistent names

    <noah> My intuition is that we'll do better to challenge ourselves
    to start by making this as focused and narrow as possible. If more
    general principles emerge, we'll find them.

    <noah> I'm very nervous about the top down view of how languages
    evolve.

    relation between persistent names and evolution on what names
    represent

    See [21]ACTION-595 Draft a report on Mime and the Web

      [21] http://www.w3.org/2001/tag/group/track/actions/595

    <glenn> poor connectivity here at present, will attempt to rejoin
    tomorrow AM

    different pace between what is defined for email, and what is
    defined for the web

    email needs backward compatibility, web forward compatibility

    success criteria is to address 50% of the use cases listed

    <noah>
    [22]http://www.w3.org/2001/tag/products/mimeweb-2011-12-24.html

      [22] http://www.w3.org/2001/tag/products/mimeweb-2011-12-24.html

    <noah> AM: I heard versioning of languages versus versioning of
    references. Those are different things

    <noah> AM: I also heard versioning of languages versus XML
    languages.

    AM: versionning of XML vs versionning of HTML

    <noah> LM: Yes, one of David Orchard's documents was about that

    <noah> AM: I think there are good extracts from Dave's documents
    that might be useful

    AM: what about sniffing?

    <Ashok> Larry, you had a document on sniffing ... what about
    progressing that document?

    <masinter> ashok, the document on sniffing turned into issues in the
    websec tracker on the sniffing document, which i have now
    volunteered to edit

    Tim: mime type is key to the web architecture. There was also a
    model of versioning done by Jonathan

    consistent ways of identifying vesion, or relationships

    <masinter> guidelines for: when to use a new MIME type vs.
    registering a new one

    <Zakim> noah, you wanted to talk about scoping this bottom up

    <masinter> guidelines for: when to use a version indicator as a
    paramter of a MIME type

    but it's better to be very crisp on little pieces

    Noah: maybe one thing would be to say "let's take javascript, and
    figure out what people want from the mime type registration when
    javascript evolves", then same thing for one or two more languages

    jeni: being able to take a larger theory and narrow it to a specific
    use case would be to test the theory and get the use cases to
    provide feedback

    <Zakim> timbl_, you wanted to go back to the 8 use cases

    <noah> 1?

    <Zakim> noah, you wanted to focus on mime-registration related stuff

    <masinter>
    [23]https://plus.google.com/106838758956333672633/posts/BbiiK6C937V

      [23] https://plus.google.com/106838758956333672633/posts/BbiiK6C937V

    noah: working on generic versionning for XML proved very time
    consuming. this effort should focus on registering media types
    rather than telling the world how to define a language

    LM: in the preface, I made it clear that the goal was not to have
    general definition of terms, but local ones only

    <noah> NM: Larry, are you mostly buying into my suggestion that we
    scope this effort mostly to the parts necessary to tell a story
    about MIME registration

    <noah> LM: Yes, except in so far as we need to look at other bits to
    verify that they are out of scope.

    Yves: 5 use cases are about language versions, one is about
    discrepancy between advertized metadata and "real" content

    <noah> NM: I'd be much happier if the use cases said things like:
    ">MIME type registration" of evolving versions of {HTML,
    JavaScript}"

    versioning of specifications vs versioning of implementations

    Noah: HTML specs were always careful not to do big incompatible
    change to the meaning of a tag. <table> will always roughly mean a
    table. HTML 1.0 didn't have <img> at some point <img> was introduced
    and still now it means image

    this is one property of HTML that people rely on

    Noah: that can be one principle that might be outlined

    LM: happy to narrow down the issue, however there are always
    architectural issues behind
    ... I have an AI on websec to work on sniffing

    <noah> ACTION-531?

    <trackbot> ACTION-531 -- Larry Masinter to draft document on
    architectural good practice relating to registries -- due 2011-12-26
    -- OPEN

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

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

    <noah> ACTION-595?

    <trackbot> ACTION-595 -- Larry Masinter to create a report on Mime
    and the Web -- due 2011-12-29 -- OPEN

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

      [25] http://www.w3.org/2001/tag/group/track/actions/595

    <noah> ACTION-636?

    <trackbot> ACTION-636 -- Larry Masinter to update product page for
    Mime and the Web -- due 2011-12-08 -- OPEN

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

      [26] http://www.w3.org/2001/tag/group/track/actions/636

    AM: what is the ultimate goal, one large comprehensive document, or
    lots of small ones?

    the big document may never get done

    noah: we need to change our product page to be more incremental

    ashok: I would like to say 'this is the big long-range goal, and
    these are the short-term steps'

    <noah> Reword [27]http://www.w3.org/2001/tag/products/mimeweb.html
    to:

      [27] http://www.w3.org/2001/tag/products/mimeweb.html

    <noah> 1) Make clear the main goal is mime registration of evolving
    languages -- only bring in broader issues as necessary

    <noah> LM: The registry performs an important function of review
    which entries apply to which versions.

    Noah: how about stating that work on that bigger product is done and
    split it in smaller products?

    LM: might be a distraction, better to get this product

    <noah> Current goal: The goal of this activity is to help guide the
    use of MIME protocol elements in Web specifications and
    implementations, and to analyze, document, and propose solutions to
    difficulties with current effective use of MIME in the Web.

    <noah> Proposed goal: The goal of this activity is to help guide the
    use of MIME protocol elements and Mime registratoins in Web
    specifications and implementations, and to analyze, document, and
    propose solutions to difficulties with current effective use of MIME
    types and MIME registrations for languages that evolve.

    Noah: Larry will write up a product page describing goals of
    previous topic.

    <noah> ACTION-531?

    <trackbot> ACTION-531 -- Larry Masinter to draft document on
    architectural good practice relating to registries -- due 2011-12-26
    -- OPEN

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

      [28] http://www.w3.org/2001/tag/group/track/actions/531

    <noah> Leave ACTION-531 for Friday

    <noah> ACTION-595?

    <trackbot> ACTION-595 -- Larry Masinter to create a report on Mime
    and the Web -- due 2011-12-29 -- OPEN

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

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

    <noah> ACTION-595 Due 2012-01-24

    <trackbot> ACTION-595 Create a report on Mime and the Web due date
    now 2012-01-24

    <noah> ACTION-595?

    <trackbot> ACTION-595 -- Larry Masinter to draft a report on Mime
    and the Web -- due 2012-01-24 -- OPEN

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

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

    <noah> ACTION-636?

    <trackbot> ACTION-636 -- Larry Masinter to update product page for
    Mime and the Web -- due 2011-12-08 -- OPEN

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

      [31] http://www.w3.org/2001/tag/group/track/actions/636

    <noah> ACTION-636 Due 2012-01-17

    <trackbot> ACTION-636 Update product page for Mime and the Web due
    date now 2012-01-17

    <noah> Noah to help Larry with ACTION-636, capturing new directions
    from Wed 4 Jan 2012

URI Definition Discovery; Metadata Architecture

    jar: [going through product page:
    [32]http://www.w3.org/2001/tag/products/defininguris.html
    ... [reviewing schedule]
    ... idea is to make a call fro change proposals 15 Jan...

      [32] http://www.w3.org/2001/tag/products/defininguris.html

    Ashok: will you ask others beyond us?

    jar: Yes - the idea is to get community consensus. We should post
    call to linked-data and [other communities].

    … idea is to drive this issue to something.

    Noah: Do you think this will make a real difference?

    jar: I think if there is no consensus and we withdraw the resolution
    then that could [have an impact]. If we get w3c consensus then that
    could have some effect. I think the current situation is not
    tolerable.

    tim: as a member of this community - I haven't reacted yet ...

    … I think there is a technical issue here. What came out of range14
    was the 303 recommendation - that [is not good].

    … We need to work on more efficient alternatives to 303.

    … I'd like to see a conclusion that we're going to underscore the
    resolution but temper it with some engineering that will make
    systems work in practice.

    jar: that would be a great outcome.

    … I think there will be an outcome. Anything that's not the current
    situation is going to be positive.

    JeniT: how will we assess the change proposals?

    jar: we need to decide what the change proposal process would be.

    JeniT: it could be quite hard to be seen as fair in assessing them.

    jar: it would still go through w3c consensus process - through rec
    track - [no matter what the TAG process is]
    ... even a statement from the TAG that "there appears to not be
    consensus on this issue" would be positive.

    … I proposed the idea of a "town meeting" teleconference.

    <DKA> +1 to a "town meeting"

    noah: the goals look good to me.

    draft call for change proposals:
    [33]http://www.w3.org/2001/tag/2011/12/uddp/cp-call.txt

      [33] http://www.w3.org/2001/tag/2011/12/uddp/cp-call.txt

    jar: I have included a plea to review the work done so far on this
    issue.

    Jenit: how would a change proposal show adequate understanding of
    those?

    jar: good question - I imagine that if it make s claim that's
    refuted in one of the referenced documents then it's a problem. If
    it just says "there's no way to X" and the issue-57 documents gives
    a way to do X…. I should make a list of points that ought to be
    addressed. E.g. "why not just use hash URIs"..

    noah: in this round, there will be some non-objective evaluation.

    tim: we should say this is not the time to argue terminology.

    <ht> +1 to requesting terminology discussion happen elsewhere

    Jenit: If I was coming to this and thinking of writing a change
    proposal - I might be concerned that I go to the effort and it is
    rejected based on obscure reasons...

    noah: could we just say "questions are welcome on the www-tag
    mailing list".

    jenit: having a deadline for drafting change proposals and then a
    period for discussion / revision and then a final deadline when we
    will make an assessment...

    noah: ideally we should put these out for community review...

    jenit: could say "We encourage people to work together to create
    change proposals that reflect community…"

    <noah> NM: Suggest a period of community review and refinement for
    all proposals to net out a good set of alternatives.

    <noah> JAR: Good idea. Not currently in plan, but I'll add it.

    <noah> NM: Do you want to do that in the product pages?

    <noah> JAR: Yes but later.

    jar: I need to add a clause welcoming proposals from anyone and
    explain that we're going after consensus.

    JAR: call for change proposals would be accompanied by two change
    proposals: no change and withdrawal of resolution

    Ashok: Do you expect something completely novel to turn up?

    JAR: People might come up with something new, though I don't expect
    it given we've been talking about it for 10 years

    LM: I have started thinking about this in a new way: URIs as
    protocol elements, with this being a way of providing a definition
    of what the URI is for languages to use
    ... originally it sounded like discovery: "how do we discover what
    this URI means?"
    ... but the language provides the meaning to the URI
    ... and the language may choose to inherit from the definition that
    you get from resolving the URI

    NM: When this started, people accepted that you could make URIs for
    images and for people
    ... and it wasn't obvious that you couldn't respond with a 200 for a
    URI that meant a person

    LM: The HTTP protocol is defined by the HTTP RFCs, which don't say
    anything about any of this, and httpRange-14 didn't change those

    NM: There are certain words such as "representation" that different
    people read in different ways

    JAR: This is all water under the bridge

    jar: we're using URIs in RDF and how do we use them?

    larry: httprange14 did not effect any language that didn't cite it.

    tim: no httprange14 is about URLs

    larry: I didn't like httprange14 before because it tried to address
    a larger scope than it should have.

    tim: it ended up with the RDF community using URLs consistently with
    the html community.

    larry: httprange14 is in scope for RDF and not for html.

    noah: my view is that this should be a comment on status codes for
    the httpbis effort.

    jar: I only care about RDF in this discussion. What's at stake is
    the ability to refer to RDF from the Web.
    ... [going over baseline proposal:
    [34]http://www.w3.org/2001/tag/2011/12/uddp/]

      [34] http://www.w3.org/2001/tag/2011/12/uddp/

    <ht> +1 to documentation over definition

    tim: URIs should be universal

    larry: in a SOPA case the counterfeit of chanel perfume was made to
    change the DNS resolution. If I wanted to make the case that this
    perfume was counterfeit then I better not use the URI because they
    were forced to change the resolution.

    … "uncool URIs must change"

    jar: this as the persistence problem really go together. RDF also
    suffers from the persistence problem.

    larry: if you use a URI for meaning something in a context then you
    want that meaning to be persistent. If you use DNS names which you
    can't guarantee their persistence then ...
    ... another example- I make assertions about texaco and then chevron
    and texaco merger and they change all their uris to
    chevrontexaco.com...

    … you have to accept the consequence.

    … it may be that RDF2 will have a way of supplying a date context -
    please interpret these statements as being in context...

    jar: [continues through document]
    ... [35]http://www.w3.org/2001/tag/2011/12/uddp/#idp409552

      [35] http://www.w3.org/2001/tag/2011/12/uddp/#idp409552

    … I've called out places where I've generalised.

    jar: this enumerates the critical parts of the TAG resolution.

    jenit: I don't agree that the 4xx response is not a critical part.

    jar: OK I'll put it back in.
    ... it seems to me that 200 http is too much of a special case - if
    you're talking about web architecture then you're talking about
    rfc3986 retrieval - of which http 200 responses are a class.

    larry: my change proposal is to avoid the phrase "http resource."

    jar: I've already done this except where I'm quoting Roy Fielding.
    ... I give examples of ftp and data as being retrieval-oriented
    URIs.
    ... I will clarify further in the draft.

    larry: in the web, there is an ambiguity between the touch point and
    the scope of the thing referenced?

    jar: this is the reason you have documentation - to explain things.

    larry: you cannot eliminate ambiguity.

    jar: absolutely.

    larry: the resources are not what are named by the URI . I have a
    problem with "the resource in question:...

    jar: the ambiguity thing is a red herring.

    [further wordsmithing]

    jar: I'll clarify the second sentence.
    ... this is aimed at people using RDF.

    ashok: "tis is a proposal for use with RDF."

    <ht> That's a possible change proposal

    <ht> but not a change to this document

    larry: we could be happier when we say "this is RDF architecture.
    ... When you have linked data it is the function of linking data
    that you use the URI both for presentation and for meaning...

    noah: let's say there's a solution adopted for the RDF community. It
    must be the case that the "document" community does noting to
    conflict eo.

    LM: We had URIs, now we have IRIs -- you don't try to impose a
    non-backwards-compatible meaning

    JAR: If the RDF community accepts this, that's the end of the story

    NM: If there was something that was backwards-incompatible for the
    document community, then that would be a problem

    JAR: HTML doesn't have a stake in how this comes out

    LM: Do load balancers and proxies have to start respecting this?

    NM: Does Squid have to be aware of this? Is there RDF-Squid and
    Other-Squid?

    TimBL: There are things that screw you up: Firefox transparently
    follows redirects, which is fine if it's 301s or 302s, but if it
    does it with 303s then it screws you up

    JAR: 303 is already documented compatibly in HTTPbis

    NM: Let's talk about making a resolution for JAR to take this
    forward

    TimBL: I think it needs to recognise the problems with 303

    JAR: the ISSUE-57 has as its purpose to do just that
    ... this is just a baseline
    ... for change proposals
    ... I might be able to refer to the ISSUE-57 document in here
    ... there is a reference to that document in the call for change
    proposals

    HT: it's worth saying in the call that you will find in the Issue 57
    document a list of problems with the Fielding resolution
    ... different people have had different problems with it

    JAR: I like that solution
    ... There's a lot in here about fragment identifiers, even though
    it's not really part of httpRange-14

    <ht> I'm happy for the call to go out, with the minor changes
    proposed to JAR's baseliine doc't

    JAR: I just need to know whether there's anything else I need to do
    before sending out the call

    <noah> PROPOSED RESOLUTION: The TAG will circulate a call for
    proposals to (re)resolve issue httpRange-14. The call will be based
    on Jonathan Rees' "d proposal for a call for change proposals",
    which is based on the baseline draft at
    [36]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
    based on suggestions at 4 January 2012 F2F.

      [36] http://www.w3.org/2001/tag/2011/12/uddp/.

    <noah> PROPOSED RESOLUTION: The TAG will circulate a call for
    proposals to amend issue httpRange-14. The call will be based on
    Jonathan Rees' "d proposal for a call for change proposals", which
    is based on the baseline draft at
    [37]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
    based on suggestions at 4 January 2012 F2F.

      [37] http://www.w3.org/2001/tag/2011/12/uddp/.

    <noah> PROPOSED RESOLUTION: The TAG will circulate a call for
    proposals to amend issue httpRange-14. The call will be based on
    Jonathan Rees' "proposal for a call for change proposals", which is
    based on the baseline draft at
    [38]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
    based on suggestions at 4 January 2012 F2F.

      [38] http://www.w3.org/2001/tag/2011/12/uddp/.

    <timbl_> PROPOSED RESOLUTION: The TAG will circulate a call for
    proposals to amend the resolution to issue httpRange-14. The call
    will be based on Jonathan Rees' "proposal for a call for change
    proposals", which is based on the baseline draft at
    [39]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
    based on suggestions at 4 January 2012 F2F.

      [39] http://www.w3.org/2001/tag/2011/12/uddp/.

    <noah> RESOLUTION: The TAG will circulate a call for proposals to
    amend the resolution to issue httpRange-14. The call will be based
    on Jonathan Rees' "proposal for a call for change proposals", which
    is based on the baseline draft at
    [40]http://www.w3.org/2001/tag/2011/12/uddp/. Both are to be updated
    based on suggestions at 4 January 2012 F2F.

      [40] http://www.w3.org/2001/tag/2011/12/uddp/.

    <noah> Passes unanimously.

    <noah> ACTION-624?

    <trackbot> ACTION-624 -- Jonathan Rees to draft for TAG
    consideration a call for httpRange-14 change proposals -- due
    2011-12-31 -- PENDINGREVIEW

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

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

    <noah> close ACTION-624

    <trackbot> ACTION-624 Draft for TAG consideration a call for
    httpRange-14 change proposals closed

    <noah> ACTION-625?

    <trackbot> ACTION-625 -- Noah Mendelsohn to schedule followup
    discussion of [42]http://www.w3.org/wiki/HttpRange14Options (per
    agreement in Santa Clara) -- due 2011-12-21 -- CLOSED

      [42] http://www.w3.org/wiki/HttpRange14Options

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

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

    <noah> ACTION-589?

    <trackbot> ACTION-589 -- Noah Mendelsohn to work with Jonathan to
    update URI definition discovery product page Due: 2011-08-18 -- due
    2011-12-23 -- CLOSED

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

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

    <noah> ACTION-201?

    <trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW
    discussions -- due 2011-12-28 -- 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 2012-03-31

    <trackbot> ACTION-201 Report on status of AWWSW discussions due date
    now 2012-03-31

    <noah> ACTION-282?

    <trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
    metadata architecture. -- due 2012-01-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> Jonathan will bump 282 date later.

    <noah> ACTION: Jonathan to post call for change proposals to amend
    the resolution to httpRange-14 per 4 January 2012 TAG Resolution
    Due: 2012-01-17 [recorded in
    [47]http://www.w3.org/2012/01/04-tagmem-irc]

      [47] http://www.w3.org/2012/01/04-tagmem-irc

    <trackbot> Created ACTION-648 - Post call for change proposals to
    amend the resolution to httpRange-14 per 4 January 2012 TAG
    Resolution Due: 2012-01-17 [on Jonathan Rees - due 2012-01-11].

Can publication of hyperlinks constitute copyright infringement?

    DKA Product page:
    [48]http://www.w3.org/2001/tag/products/PublishingLinking-2011-12-27
    .html

      [48] 
http://www.w3.org/2001/tag/products/PublishingLinking-2011-12-27.html

    JeniT We've been kicking this draft around - Dan I have revised it
    recently.

    [49]http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2012
    -01-04.html

      [49] 
http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2012-01-04.html

    JeniT following discussion with Rigo - the direction he recommended
    was to have this doc focused on technical aspects of publishing and
    linking and to have some other mechanism for having stronger
    statements that we want to make - e.g. right to link, flagging
    issues with transforming proxies, etc - questions with legal
    questions associated with them.

    …. we want to answer 3 main questions today. First, is that a
    reasonable way forward; 2nd if so what is the best mechanism for
    making those opinion statements?; 3rd given that we make those
    statements, what statements should we make?

    … so first question - is that a reasonable way to structure this
    work?

    Larry There are different kinds of opinions. There are opinions
    about the technical impact are and opinions about legislation. I
    wanted you to separate out the opinions about legislations from the
    technical opinions.

    JeniT yes - that's what we've done for the latest draft.

    Noah: it strikes me as the right direction to try.

    Dan: this is based on some additional feedback from Rigo.

    Jenit: what should the opinion statements be?

    <masinter> You can remove opinions about legal without removing
    opinions about control

    Dan: Bullet points on messages we want to convey. We have taken
    these out of the document.

    Jeni writes on board "hosting != possesion"

    Larry: Can we keep this in the document rephrased as technical
    point?

    <masinter> ""It is impossible to control dissemination of
    content-based unwanted material, merely by imposing restrictions on
    service providers offering transformation services, because such
    services are not able to differentiate wanted form unwanted content.
    The result would be severely limited services, instead.""

    <masinter>
    [50]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0120.html

      [50] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0120.html

    Dan: Rigo would feel this would be better left out
    ... this is opinion

    Larry: If you cannot distinguish what you can publish and what you
    cannot, you cannot publish anything
    ... distinguish mechanically at reasonable cost

    <masinter> "common carrier"

    Noah discusses wording re automated algorithms to distinguish ...

    scribe: what you can publish and what you cannot
    ... copyrighted vs. non-copyrighted material

    Peter: A lawyer you not care whether it is automated or not

    <masinter> in the "legal opinion" view, I'd want to make web hosting
    and transformation services to be "common carriers"

    Jar: I think you can consider making the point without using legal
    ... you can talk about requirements

    <jar> System requirements come from a variety of sources. Laws and
    contracts are just particular examples of requirement sources. So
    talk about requirements, and avoid any hint that some legal
    assessment is being made.

    Jeni: We want to separate the two documents: legal and technical

    Larry: Goverments do not have to make things illegal in order to
    prohibit them

    Jeni writes on board "filtering content can be hard".

    Larry: We should point about other means of control other than
    criminalization

    Dan: We can work in parallel on these two things ... first publish
    the technical work

    Jeni writes "copying is needed for proxying /archiving"

    Jeni writes "rewriring links is necessary for archiving"

    Jeni writes "transforamation is needed for search engines"

    Jeni writes "users don't know where they are going when they click
    on a link/prefetch"

    Jeni writes "deep linking is necessary -- right to link

    <jar> greasemonkey is a terrific innovation… but may be incompatible
    with requirements

    scribe: linking is a speech act
    ... network effects

    Dan: A speech act is something that is protected under UN Resolution
    ...

    <noah> NM: I agree. I'm happy to see the TAG talk about the
    importance of network effects & Metcalfe's law. I'm happy to see
    >the W3C< make the connection to UN Resolutions. I don't see the
    technical content that makes the connection to the UN part of the
    TAG's remit at W3C.

    Larry: Protocols should be explicit whether links imply automatic
    behaviour without additional action

    Jeni writes " linking vs. inclusion"

    Larry: Links could be speech acts or automatic actions

    Noah disagrees ... points to separation of concerns. Links can be
    processsed in different ways

    Larry: Protocols could annotate links to indicate whether link
    should be followed

    Jeni: Topics on board are examples we can pull out to talk about
    legislation or contracts, etc.

    Ashok: These are good starting statements

    Most people in room think this is a good direction

    Tim: "It would be reasonable for a Goverment to conclude that ..."

    Larry: In telecom field this is the legal Common Carrier issue ...
    does this translate to web hosting etc. ?
    ... used in Common Law Countries

    Dan: Article 19 on Human Rights ... fundamental right

    Jeni: Moving to vehicle ... how to disseminate these points

    Noah: We need a base technical document with good, simple,
    non-inflammatory examples
    ... We can decided how to disseminate on a case-by-case basis
    ... two documents technical document and a document with examples.
    ... perhaps combine into one document

    Larry: Perhaps ask ISOC for some help

    Noah: We should publish our document first

    Discussion about updating the product page

    Ashok: We need a new mechanism to put W3C positions front and center

    Tim: Perhaps Web Foundation could pick that up

    Larry: This seems the main thing that ISOC does ... we could get
    them the technical background

    jar: But this project is about what we think ... voice of the
    technical community

    Yves: Most impt thing is to publish the technical document

    <jar> +1

    Dan: Let's publish the technical document and then debate how to
    disseminate the other stuff

    Larry: Should we review your latest documemt?

    jar: Technical document could have some compelling examples

    <jar> The main (tech) document can contain plenty of compelling
    examples, based on general system requirements (not on legal
    considerations)

    <jar> (which is similar to what I think Larry was saying earlier,
    about administrative control)

    <noah>
    [51]http://www.w3.org/2001/tag/2012/01/CopyrightLinkingTopics.jpg

      [51] http://www.w3.org/2001/tag/2012/01/CopyrightLinkingTopics.jpg

    <noah> ACTION-627?

    <trackbot> ACTION-627 -- Noah Mendelsohn to schedule very detailed
    line-by-line review of Pub&Linking draft at January F2F -- due
    2011-12-23 -- PENDINGREVIEW

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

      [52] http://www.w3.org/2001/tag/group/track/actions/627

    <noah> need to reopen 627 until draft is ready

    <noah> Never mind

    <noah> ACTION-627 Due 2012-01-10

    <trackbot> ACTION-627 Schedule very detailed line-by-line review of
    Pub&Linking draft at January F2F due date now 2012-01-10

    <noah> ACTION-627 Due 2012-01-17

    <trackbot> ACTION-627 Schedule very detailed line-by-line review of
    Pub&Linking draft at January F2F due date now 2012-01-17

    <noah> ACTION-629?

    <trackbot> ACTION-629 -- Daniel Appelquist to with help from Jeni to
    propose changes to goals, success criteria etc. for
    publishing/linking product page -- due 2011-11-11 -- OPEN

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

      [53] http://www.w3.org/2001/tag/group/track/actions/629

    <noah> ACTION-629 Due 2012-01-17

    <trackbot> ACTION-629 With help from Jeni to propose changes to
    goals, success criteria etc. for publishing/linking product page due
    date now 2012-01-17

    <noah> ACTION-541?

    <trackbot> ACTION-541 -- Jeni Tennison to helped by DKA to produce a
    first draft of terminology about (deep-)linking etc. -- due
    2011-12-20 -- OPEN

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

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

    <noah> Changing description

    <noah> ACTION-541?

    <trackbot> ACTION-541 -- Jeni Tennison to helped by DKA to produce
    draft on technical issues relating to copyright/linking -- due
    2012-01-31 -- OPEN

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

      [55] http://www.w3.org/2001/tag/group/track/actions/541

    <noah> ACTION: Jeni to produce a document with examples motivating
    the technical points in the Copyright/Linking document Due:
    2012-03-20 recorded in [56]http://www.w3.org/2012/01/04-tagmem-irc]

      [56] http://www.w3.org/2012/01/04-tagmem-irc

    <trackbot> Created ACTION-649 - Produce a document with examples
    motivating the technical points in the Copyright/Linking document
    Due: 2012-03-20 [on Jeni Tennison - due 2012-01-11].

Summary of Action Items

    [NEW] ACTION: Ashok to draft product page on client-side storage
    focusing on specific goals and success criteria Due: 2012-01-17
    recorded in [57]http://www.w3.org/2012/01/04-tagmem-irc]
    [NEW] ACTION: Jeni to produce a document with examples motivating
    the technical points in the Copyright/Linking document Due:
    2012-03-20 recorded in [58]http://www.w3.org/2012/01/04-tagmem-irc]
    [NEW] ACTION: Jonathan to post call for change proposals to amend
    the resolution to httpRange-14 per 4 January 2012 TAG Resolution
    Due: 2012-01-17 [recorded in
    [59]http://www.w3.org/2012/01/04-tagmem-irc]

      [57] http://www.w3.org/2012/01/04-tagmem-irc
      [58] http://www.w3.org/2012/01/04-tagmem-irc
      [59] http://www.w3.org/2012/01/04-tagmem-irc

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [60]scribe.perl version 1.136
     ([61]CVS log)
     $Date: 2012/01/13 21:33:37 $

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


================== 5 January 2012 =====================

    [1]W3C

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

                                - DRAFT -

    Technical Architecture Group Face-to-Face Meeting -- 05 Jan 2012

05 Jan 2012

    [2]Agenda

       [2] http://www.w3.org/2001/tag/2012/01/04-agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2012/01/05-tagmem-irc

Attendees

    Present
           Glenn_Adams_(by_phone), Dan_Appelquist, Tim_Berners-Lee,
           Yves_Lafon, Philippe_Le_Hegaret_(part), Peter_Linss,
           Ashok_Mahotra, Larry_Masinter, Noah_Mendelsohn,
           Jonathan_Rees, Wendy_Seltzer_(part), Jeni_Tennison,
           Henry_Thompson_(part, by_phone), Norm_Walsh_(part, by_phone)

    Regrets

    Chair
           Noah Mendelsohn

    Scribe
           Jonathan Rees, Ashok Mahotra

Contents

      * [4]Topics
          1. [5]Administration
          2. [6]Microdata + RDFa
          3. [7]HTML.next
          4. [8]Privacy
          5. [9]TAG Priorities for 2012
          6. [10]XML/HTML Convergence
      * [11]Summary of Action Items
      _________________________________________________________

    <jar> scribenick: jar

    <timbl> Larry, document RDF is at
    [12]http://www.w3.org/2002/01/tr-automation/tr.rdf

      [12] http://www.w3.org/2002/01/tr-automation/tr.rdf

Administration

    agenda review

    F2F scheduling

    Next F2F is April 2-4 in the south of France.

    <glenn> I have a conflict for week of Jun 11-15 should I be elected

    <ht> I cannot do 25 or 29 may

    <ht> should I be re-elected

    <noah> We are talking about 12-14 June in Cambridge, to meet Tim's
    preferences. Can you do it?

    <ht> Yes

    <glenn> I will be in London that week

    The TAG plans to meet 12-14 June, but please don't make travel plans
    yet since we need to consult with new members.

    ht: It would be good for every TAG member to touch base with an IETF
    meeting, IMO

    LM: Let's talk to Mark N about liaison when he's here. Might be good
    to interact with ISOC too
    ... maybe collaborate around extensibility

    <masinter> suggestions for IETF general topics: (a) ask MNot on
    Friday (b) IAB on extensibility, (c) ISOC members on legal impact.

    <masinter> suggestions for individual TAG members of relevant IETF
    working groups: RTC, IRI, URNbis, HTTPbis, websec. If you attend, be
    prepared to have read relevant documents being discussed

Microdata + RDFa

    <JeniT> [13]http://www.w3.org/wiki/Html-data-tf

      [13] http://www.w3.org/wiki/Html-data-tf

    JT: We have had wiki page set up since September. Two documents came
    out of this

    <JeniT>
    [14]https://dvcs.w3.org/hg/htmldata/raw-file/default/html-data-guide
    /index.html

      [14] 
https://dvcs.w3.org/hg/htmldata/raw-file/default/html-data-guide/index.html

    JT: HTML data guide - advice on how to do data in HTML, when to use
    which mechanism
    ... divided by target audiences
    ... Publishers: how to mix vocabularies, how to mix syntaxes - what
    do you have to be aware of re possible conflicts
    ... Next section is for consumers - what syntax should you consume,
    how to deal with mixed input
    ... 3rd section is for vocabulary authors. Extending existing
    vocabularies to suit new requirements, designing vocabs for each
    kind of syntax and that work across the syntaxes
    ... The plan is to publish this as a SWIG note in January

    LM: What I'm missing is anything about whole-document metadata - DC,
    XMP - I know this is a different problem, but some ack of this would
    be nice
    ... The HTML meta tag seems related. The document ought to say
    something about this other stuff, if only to put it out of scope.
    ... There should be references so that readers are directed to the
    right place (if they want to know about it)

    TBL: question about history of RDFa
    ... Dublin Core was persuaded to adopt RDF with the understanding
    that RDFa would be coming along later

    NM: Didn't the current [Microdata + RDFa] effort start with the
    announcement of schema.org ? How have things progressed since then?

    <masinter> "whole document metadata" is a separate but related topic
    but likely to be confused

    JT: RDFa Lite is now a WD, schema.org has adopted support for it

    <masinter> and
    [15]http://www.w3.org/TR/REC-rdf-syntax/#section-rdf-in-HTML

      [15] http://www.w3.org/TR/REC-rdf-syntax/#section-rdf-in-HTML

    JT: Google already recognized a wide variety of markups, and
    schema.org was a statement of a preferred form

    NM: It would be nice to be able to tell the community what the TAG's
    role was in this

    <masinter> also:
    [16]http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecifi
    cation.pdf#page=98 embedding XMP in HTML

      [16] 
http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf#page=98

    <timbl> 2003-12-15 XFN 1.0 launched by Tantek Ãelik[$1\47], Eric
    Meyer[$1\47], Matthew Mullenweg[$1\47]

    <timbl> a b "XHTML and RDF W3C Note 14 February 2004". World Wide
    Web Consortium. 2004-02-14. Retrieved 2007-12-27.
    [17]http://www.w3.org/MarkUp/2004/02/xhtml-rdf

      [17] http://www.w3.org/MarkUp/2004/02/xhtml-rdf

    ashok: So there wasn't a groundswell to reduce the number of
    formats? Why not?

    LM: I thought the big difference had to do with namespaces and
    extensibility? You can use namespaces in RDFa but not in microdata?

    <masinter> i'm also concerned about relationship between embedded
    metadata in linked images and metadata in links

    JT: Not really. In microdata you can have multiple independent event
    vocabularies
    ... In microdata syntax you can't say a single item is two things
    from two different vocabularies... but you can always nest

    <JeniT>
    [18]https://dvcs.w3.org/hg/htmldata/raw-file/default/microdata-rdf/i
    ndex.html

      [18] 
https://dvcs.w3.org/hg/htmldata/raw-file/default/microdata-rdf/index.html

    TBL: What about getting triples out of HTML documents?

    JT: That's the second document.
    ... There were problems with the HTML5 mapping of microdata to RDF

    <masinter> for example,
    [19]http://www.metadataworkinggroup.org/specs/ deals with
    relationship. For example, img src="something.jpeg" might want to
    link data about the image in the HTML, to ... override? supplant? be
    resolved against ? metadata ... may need something of the scope of
    [20]http://www.metadataworkinggroup.org/specs/

      [19] http://www.metadataworkinggroup.org/specs/
      [20] http://www.metadataworkinggroup.org/specs/

    JT: The problem is it's impossible to generate idiomatic RDF without
    some knowledge of the microdata vocabulary.

    <masinter> would like to make sure review with
    [21]http://www.w3.org/2008/WebVideo/Annotations/ happens

      [21] http://www.w3.org/2008/WebVideo/Annotations/

    JT: It doesn't make distinctions that RDF makes. E.g. what about
    ordering of multiple values? Microdata is always ordered, but in
    idiomatic RDF it would depend on vocabulary
    ... AFAIK everyone using microdata is using schema.org

    TBL: Could you annotate the schema?

    JT: Somewhere, somehow, there needs to be a registry that provides
    this information

    <JeniT> [22]http://dev.w3.org/html5/md/Overview.html#items

      [22] http://dev.w3.org/html5/md/Overview.html#items

    <JeniT> "Except if otherwise specified by that specification, the
    URLs given as the item types should not be automatically
    dereferenced."

    <noah> We need to wrap this discussion in 2 minutes

    jar: asking why there needs to be a canonical mapping for microdata
    (as opposed to lots of mappings)

    noah: Cost/benefit

    TBL: Scaling and reuse

    <Zakim> masinter, you wanted to ask that the HTML data guide address
    other workflows around data management in HTML: merging HTML from
    multiple sources, merging HTML data with data from

    <JeniT>
    [23]https://dvcs.w3.org/hg/htmldata/raw-file/default/html-data-guide
    /index.html#consuming-multiple-formats

      [23] 
https://dvcs.w3.org/hg/htmldata/raw-file/default/html-data-guide/index.html#consuming-multiple-formats

    <JeniT> I think that's expanding the scope which I don't want to do

    LM: metadata about the linked object in the referring document -
    this is a common workflow - possible conflicts - might be worth
    calling this out

    <JeniT> That might be useful, but it's outside scope

    <masinter> if it is out of scope, then please note that it hasn't
    been addressed and should be before the analysis is complete

    NM: Thanks Jeni

    JT: There's so much to say about this, we had to keep the scope
    quite narrow

    <timbl> I wonder why "This section is non-normative.

    <timbl> This document describes a means of transforming HTML
    containing microdata into RDF. "

    <JeniT> [24]http://www.w3.org/html/wg/next/markup/

      [24] http://www.w3.org/html/wg/next/markup/

HTML.next

    nm: I'd like to know what we ought to be doing re HTML.next in the
    next 3-6 months

    PLH: Mike Smith did some work since we last spoke about this. New
    list [of features], which is interesting
    ... E.g. datagrid got removed from html5, deferred
    ... Input mode attribute, proposal from Microsoft

    NM: Looks like none of this is deep

    PLH: There will be no upgrades to the HTML5 parsers

    NM: That's important

    <masinter> modularization of the specification?

    <glenn> the proposed "element" and "template" element types appear
    somewhat generic

    PLH: intent element - from device API WG - for head - this is a
    problem since an HTML5 parser will treat unrecognized an element in
    the head as transition to body

    <masinter> which of [25]http://www.w3.org/2010/11/TPAC/HTMLnext.pdf
    are in scope?

      [25] http://www.w3.org/2010/11/TPAC/HTMLnext.pdf

    <masinter> and my own perspective:
    [26]http://www.w3.org/2010/11/TPAC/HTMLnext-perspectives.pdf

      [26] http://www.w3.org/2010/11/TPAC/HTMLnext-perspectives.pdf

    TBL: This has always been a bug... unrecognized head elements ought
    to be ignored, otherwise there's no extensibility

    PLH: intent is thus an example of an extension that's NOT going to
    be considered for now
    ... ('intent' is a misnomer)

    NM: it has a pub/sub feel to it

    PLH: Arrival of speech on the web is going to be a big item. Speech
    incubator group is looking at it
    ... translate - if you don't use namespaces, that's OK, but [scribe
    missed]
    ... translate will be part of HTML, but will be extended further

    <plh> --> [27]http://www.w3.org/2011/12/mlw-lt-charter.html
    Multilingual Web Working Group Charter

      [27] http://www.w3.org/2011/12/mlw-lt-charter.html

    NM: Before ratholing, remember the goal is what the TAG should be
    doing

    JAR: What about javascript related changes?

    PLH: Being able to control adaptive streaming algorithm - it's a set
    of APIs
    ... Javascript modules is not part of this discussion

    LM: What I see is sets of features, which seems appropriate for the
    WG

    <glenn> plh? impact from media related proposals in
    [28]http://www.w3.org/wiki/HTML/next#Multimedia ?

      [28] http://www.w3.org/wiki/HTML/next#Multimedia

    LM: at TPAC there was an interesting panel ... architectural
    conflicts between SVG (etc.) and HTML, things left dangling,
    references to evolving specifications
    ... these are not features, but they are changes to the
    specification and affect evolution of the language. Maybe the WG
    doesn't want to work on this, as this is painful
    ... might the TAG be able [to do anything] to make that kind of work
    easier to do?

    PLH: SVG and HTML video element conflict will be addressed by the
    WGs

    <glenn> plh? accessibility issues from use of canvas ? is this in
    HTML.next scope ?

    PLH: there is interest in making the technologies work well together

    LM: color management

    PLH: this is happening naturally, since implementors don't like to
    implement the same thing twice with variation

    LM: But that kind of pressure is not neceesarily enough

    PLH: The CSS extensibility story has been falling apart. Market
    successes drive out minority features...

    PL: If an id contains a - then it will never become part of CSS
    (this includes vendor prefixes)
    ... When people started using vendor prefixes for experimental
    purposes that was a problem

    TBL: Pain

    PL: Any vendor who does [that] will get a whack from the CSS WG

    LM: The question is who to blame when something goes wrong

    PLH: I introduced this topic because CSS seems to have the best
    extensibility story for experimental features

    PL: The best approach is for the CSS WG to drive new features to rec
    as fast as possible, to avoid vendor prefixes

    LM: Vendor prefixes should have a year, and old features should not
    be used

    <masinter> What can the TAG do? Extensibility, mdularization,
    references... architectural features

    <glenn> what is the record for attaining REC by CSS WG? 2-3 out of
    20-30 specs? some specs going on 10+ years

    NM: XML namespaces often feel like vendor prefixes. There's not a
    good way to say what the implementation path is for [missed]

    LM: How can the TAG help? Not with the feature list. What about
    architectural issues, like extensibility, maybe narrowly focussed.

    PLH: Because no namespace support, we're trying to keep track of new
    elements being introduced
    ... [in HTML]

    TBL: HTML parser is a big black box, not driven by tables, no
    grammar - so how to add new elements?

    <masinter> timbl: table driven parser? Grammar? If you're adding new
    elements, where will they be added?

    PLH: Some parts of parser are going to be unchanged - error recovery

    LM: What about HTML5 issues closed for lack of change proposal?
    Reconsidering them for HTML6?

    PLH: Correct, this can happen.

    JT: Has there emerged a kind of scope for HTML.next? Or timeline?

    PLH: Should be more rapid this time

    <noah> ACTION-600?

    <trackbot> ACTION-600 -- Daniel Appelquist to report to TAG on
    goals, scope and progress to date for HTML.next work -- due
    2011-10-25 -- OPEN

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

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

    <noah> DKA: No progress on ACTION-600

    <noah> NM: I think we'll probably reassign ACTION-600 given that Dan
    is leaving the TAG, let's see how the rest of this discussion goes.

    <noah> ACTION-641?

    <trackbot> ACTION-641 -- Noah Mendelsohn to try and find list of
    review issues relating to HTML5 from earlier discussions -- due
    2012-01-17 -- OPEN

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

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

    <noah> I'm sorry I didn't have time to get to ACTION-641. It's due
    mid-Jan. Not sure if I'll get to it, but I'll try. Help would be
    welcome.

    PLH: There's the issue of modularizing the spec. To some extent this
    happens because different people are working on different parts

    <glenn> negative impact of modularization is cross-dependencies
    between modules and time lines for completion of dependencies

    NM: The TAG isn't looking for work, the question is whether we can
    be of any use

    <glenn> separately, there are core semantics of HTML5 spec (such as
    event queue semantics) that are being normatively referenced by many
    other specs in other WGs (e.g., WebApps)

    <glenn> it's becoming quite a nest of dependencies with little
    architectural planning for the impact

    LM: We're not looking for trouble. Can we look to Philippe to bring
    to our attention anything the TAG might help with?

    <noah> PROPOSED RESOLUTION: The TAG decides that it will not at this
    time start a significant effort on HTML.next. Therefore: 1)
    HTML.next will be removed from the under consideration list on the
    TAG product list 2) ACTION-600 will be closed. The TAG will look to
    PLH and others to engage the ...

    <noah> TAG as appropriate on HTML.next issues.

    RESOLUTION: The TAG decides that it will not at this time start a
    significant effort on HTML.next. Therefore: 1) HTML.next will be
    removed from the under consideration list on the TAG product list 2)
    ACTION-600 will be closed. The TAG will look to PLH and others to
    engage the TAG as appropriate on HTML.next issues.

    <noah> close ACTION-600

    <trackbot> ACTION-600 Report to TAG on goals, scope and progress to
    date for HTML.next work closed

    LM: Request that MIME type registrations happen sooner
    ... You can say that there is no specification yet - register a
    placeholder
    ... W3C has been too conservative, better to err on the side of
    aggressive registration
    ... Enough about specs, it's time to start registering
    ... I want the official registry to be better than what you find in
    wikipedia

    JT: Talking about media type registries - I had an action re FYN

    LM: If specs are allowed to fork, maybe they shouldn't contain their
    own media type registration, since the reg has to talk about the
    fork

    <JeniT> ACTION-642?

    <trackbot> ACTION-642 -- Jeni Tennison to with help from Larry to
    make plan of action for getting "follow your nose" for (at least)
    microdata and RDFA from HTML5 Due: 2 January 2012 -- due 2012-01-02
    -- OPEN

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

      [31] http://www.w3.org/2001/tag/group/track/actions/642

    LM: Consider the existence of "profiles" - the pointer to the main
    spec would be just one piece of information
    ... I want to figure out whether Philippe might need help [with any
    aspect of the reg. process]

    NM: Is profile still out?

    PLH: Are you looking for a text/html registration that is really
    vague?

    LM: I was looking for a reg that talks about what someone receiving
    a document [so marked] would get

    NM: Document misuses of the MIME type.

    LM: MIME is the wrong place to talk about conformance or
    correctness.
    ... MIME is informational to receivers.

    NM: The reg. makes promises: if doc is well formed it has such and
    such a meaning (DOM, etc.)

    LM: 3023 is a spec, and you can conform or not. It sets out
    conformance criteria.

    <JeniT> plh, what I'm worried about is the follow-your-nose from an
    HTML document to understanding how the HTML document should be
    processed...

    TBL: The arch goes thru media type, that means you're part of a
    protocol, you're committing to a particular meaning
    ... MIME type is a key piece of this, normative

    <JeniT> plh, which can't currently happen because there's no route
    from the mime type to the various extensions made to HTML

    <JeniT> plh, so I guess the question is: where is the registry of
    the set of HTML extensions (such as microdata, RDFa)

    <plh> doesn't exist at the moment

    LM: Let me try to restate. When you register, you're saying two
    things, one to consumers, one to producers. Advice to consumers has
    to be realistic - even for non-conforming docs

    NM: When something's put on the wire, there are inferences that can
    be drawn from the specs
    ... It's a contract
    ... If you send me garbage, then nothing can be inferred per the
    registration

    [but can be inferred some other ways?]

    LM: The spec is extensible - extensions are legit according to the
    spec - even though not written at the time the spec is written

    NM: Is error recovery language in HTML used for ...?

    [scribe couldn't distill what NM just said into something that could
    be written down]

    NM: Fully legal, expect it but deprecated, tolerate it
    interoperably, ...
    ... If you see a new element name, maybe it comes from a future spec

    LM: Jeni's action was to connect text/html to RDFa. No simple way to
    fix that if RDFa isn't listed in the media type reg.
    ... A registry of HTML extensions would solve this problem

    JT: Could W3C do this?

    jar: W3C already does this for XHTML (XHTML namespace document)

    NM: What should the TAG's involvement be in the text/html media type
    registration?

    PLH: No request sent yet

    NM: Maybe TAG should be more actively involved

    LM: There's currently a W3C policy that the media type reg is in the
    language spec, because unlinking led to mismatches. This is probably
    OK in many cases, but I'm not sure about text/html

    <glenn> other obligations for today, will rejoin in morning

    <noah> NM: I think the next step on media type registration would be
    to get a balanced analysis of potentially controversial or
    architecturally tricky points regarding the media type registration.
    Then we can see if there's anything the TAG needs to engage.

    <noah> JT: We can rescope my ACTION-642 to cover that.

    <noah> NM: Great, fine with me. Thank you.

    <noah> ACTION-642

    <noah> ACTION-642?

    <trackbot> ACTION-642 -- Jeni Tennison to with help from Larry to
    make plan of action for getting "follow your nose" for (at least)
    microdata and RDFA from HTML5 Due: 2 January 2012 -- due 2012-01-02
    -- OPEN

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

      [32] http://www.w3.org/2001/tag/group/track/actions/642

    <noah> New scope: JT with help from Larry to report on potential
    issues requiring TAG attention relating to HTML media type
    registration.

    <masinter> it says "at least"

    <JeniT> "JT with help from Larry to liaise with PLH to register HTML
    media type

    <noah> "JT with help from Larry to propose plan to liaise with PLH
    to register HTML media type

    NM: what about what TAG is doing, as opposed to TAG members. [scribe
    mistranscription]

    <noah> ACTION-642?

    <trackbot> ACTION-642 -- Jeni Tennison to with help from Larry to
    propose plan to liaise with PLH to register HTML media type -- due
    2012-01-17 -- OPEN

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

      [33] http://www.w3.org/2001/tag/group/track/actions/642

    <masinter> i liked the old action item better, because it recorded
    why we're doing it

    break ending

Privacy

    Welcome Wendy Seltzer

    introductions

    WS: EFF, Berkman, now W3C team

    <masinter>
    [34]http://masinter.blogspot.com/2011/08/internet-privacy-telling-fr
    iend-may.html

      [34] 
http://masinter.blogspot.com/2011/08/internet-privacy-telling-friend-may.html

    <masinter> my contribution to the privacy discussion

    NM: privacy, big issue, potential threat to the web. DNT

    <noah>
    [35]http://lists.w3.org/Archives/Public/www-tag/2012Jan/0000.html

      [35] http://lists.w3.org/Archives/Public/www-tag/2012Jan/0000.html

    ashok: The idea was to look at privacy from higher level. There is a
    DNT WG, that's good, but it's just a corner of the "war on personal
    privacy"

    <masinter> want to ask about ISOC and
    [36]http://www.internetsociety.org/our-work-privacy

      [36] http://www.internetsociety.org/our-work-privacy

    ashok: leaks from social networks
    ... picking up ambient information
    ... identifying based on clicks etc.

    <masinter> [37]http://www.ietf.org/rfc/rfc3514.txt

      [37] http://www.ietf.org/rfc/rfc3514.txt

    ashok: Not a technological problem. Encryption may be helpful, but
    not clear how far it can go
    ... Accountability, laws as non-technological alternative
    ... Mitigations? Technical, policy, education

    DKA: Data minimization as technical mitigation - granularity - this
    is privacy-enhancing

    <masinter> What is relationship of W3C role in privacy to other
    initatives

    jar: Interesting:
    [38]http://dataprivacylab.org/projects/irb/index.html

      [38] http://dataprivacylab.org/projects/irb/index.html

    DKA: I got negative feedback from the geolocation WG - they ask, who
    is asking for this?

    <DKA> Draft API Data Minimization finding:
    [39]http://www.w3.org/2001/tag/doc/APIMinimization.html

      [39] http://www.w3.org/2001/tag/doc/APIMinimization.html

    NM: Here are 2 things. 1, possibility of more traffic encryption,
    cf. SPDY.. performance limited devices, cost of encryption. 2.
    Fingerprinting, e.g. browser configuration uniqueness . These are
    technical topics

    <Zakim> masinter, you wanted to ask why this is TAG work... argue
    against TAG taking this as a major area, not so much because of
    "lack of expertise" as "already covered". to respond to

    YL:

    LM: W3C is a focus of policy initiatives that aren't asked for by
    developers. Constituencies come to us
    ... Many past difficulties around privacy have to do with venue
    shopping, esp between W3C and IETF.
    ... Encryption is a red herring. Does nothing for privacy

    <timbl> Sweeping generalizations are always wrong -- and Larry's is
    no exception.

    LM: Why is this TAG work? Seems like W3C work, but not TAG work -
    not technical. Not interested in stopgaps

    <masinter> it isn't that it is "not technical", it's that any TAG
    work would be without sufficient context to be useful

    <masinter> "Not interested in stopgap" => "DNT is stopgap, we
    shouldn't do too many more of those"

    <masinter> encryption doesn't help much with almost all of the
    privacy threats i can think of

    <DKA> For the record: I feel the data minimization is relevant to
    the TAG since it is articulating an architectural principle - a
    design best practice - that also happens to enhance privacy.

    <masinter> @dka: it might be an architectural principle, but it's
    not clear it really helps in most of the threat cases, and it's not
    actionable

    NM: Look at work plan...nothing much here re privacy, barely started

    RESOLUTION: The TAG will not do a major effort on privacy at this
    point. We will remove Privacy from the list of active projects.

    WS: The framing is a good start. Threat categories: p2p, corporate,
    individual to government - different concerns re different info
    collectors

    LM: [What are the] threats?

    WS: Info used out of context

    LM: Is there a sense that these are more than a list of anecdotes?
    ... What W3C could do: try to ground anecdotal tales about
    hypothetical instances, in real cases
    ... If we had a better model of the real threats, we could do better
    at responding, with technical architecture

    WS: We can do better at describing

    LM: We need the particular cases - not a categorization - we already
    have good descriptions of categories, but they seem to be based on
    hypotheticals
    ... need grounding in fact

    TBL: [one might mine them from] risks digest
    [40]http://catless.ncl.ac.uk/Risks

      [40] http://catless.ncl.ac.uk/Risks

    <masinter> a real threat analysis

    <wseltzer> "concern" can be a harm too

    <DKA>
    [41]http://online.wsj.com/public/page/what-they-know-digital-privacy
    .html

      [41] 
http://online.wsj.com/public/page/what-they-know-digital-privacy.html

    <wseltzer> ...if people are deterred from using the web based on
    concerns that their information may be misused

    <masinter> concern can be caused by rumors too

    <masinter> many people are concerned about 12/11/12 or whenver the
    mayan calendar says the world will end

    <masinter> would encryption help with any of the issues in
    [42]http://online.wsj.com/public/page/what-they-know-digital-privacy
    .html ?

      [42] 
http://online.wsj.com/public/page/what-they-know-digital-privacy.html

    discussion of what to do, and who to do it

    <wseltzer> encryption could prevent some of the snooping by
    middlemen

    <Yves> encryption could also lead to misplaced trust (in case of CA
    attacks, for example)

    <noah> WS: I'm here to work on Web Identity.

    action jar to review what provenance WG is doing with an eye to
    application to privacy issues

    <trackbot> Created ACTION-650 - Review what provenance WG is doing
    with an eye to application to privacy issues [on Jonathan Rees - due
    2012-01-12].

    <noah> WS: Part of that is getting the privacy story right, and
    helping users to understand the implications of what they're doing
    on the Web

    <noah> ACTION-566?

    <trackbot> ACTION-566 -- Daniel Appelquist to contact Alissa Cooper,
    organize a future joint discussion on privacy with IAB. -- due
    2011-10-18 -- OPEN

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

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

    <masinter> [44]http://www.internetsociety.org/our-work-privacy

      [44] http://www.internetsociety.org/our-work-privacy

    <masinter> see
    [45]http://www.ietf.org/proceedings/81/technical-plenary.html

      [45] http://www.ietf.org/proceedings/81/technical-plenary.html

    adjourn for lunch

    <Norm> I'm hitting the road. Noah, you've got my mobile if you need
    to reach me. See y'all this afternoon.

    <Ashok> scribenick: Ashok

TAG Priorities for 2012

    Noah: We published a finding on Web Application State.
    ... need to deal with Raman's document
    ... I suggest we move Web App State to the completed state

    LM: Did we get community review?

    Noah: We may want to do more to promote it and ask folks if it
    helped them

    LM: Any reason not to make this rec track?

    Jar: Findings should make their way into architectural
    recommendations

    RESOLUTION: The TAG, having published a finding on Web Application
    State, closes its "product" on that topic.

    <noah> ACTION: Noah to announce closing of Web App State Product
    Due: 2012-01-17 [recorded in
    [46]http://www.w3.org/2012/01/05-tagmem-irc]

      [46] http://www.w3.org/2012/01/05-tagmem-irc

    <trackbot> Created ACTION-651 - Announce closing of Web App State
    Product Due: 2012-01-17 [on Noah Mendelsohn - due 2012-01-12].

    <noah> &#8212; <span class="needswork">product page
    needed</span>)</td>

    <noah> <td>Daniel Appelquist, Ashok Malhotra</td>

    <noah> <td class="needswork">TBD</td>

    <noah> </tr>

    [47]http://www.w3.org/2001/tag/products/ is the list of stuff we are
    working on

      [47] http://www.w3.org/2001/tag/products/

    Noah: Frag Identifiers and Mime Types is late

    <noah> ACTION-594?

    <trackbot> ACTION-594 -- Peter Linss to with Henry produce partial
    revision of fragment id finding -- due 2011-10-18 -- OPEN

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

      [48] http://www.w3.org/2001/tag/group/track/actions/594

    Yves: I will work on that

    <noah> ACTION-594?

    <trackbot> ACTION-594 -- Yves Lafon to with Peter and Henry produce
    partial revision of fragment id finding -- due 2012-02-14 -- OPEN

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

      [49] http://www.w3.org/2001/tag/group/track/actions/594

    LM: Should we integrate this with the other MIME stuff?

    JT: I think it's better to keep a tight scope

    Noah: The TAG agreed to invest in this effort starting by revisiting
    the work plan.

    (Noah updates the product page)

    Noah: Publishing and Linking on the Web remains a top priority
    ... URI Discovery remains a top priority
    ... MIME architecture for the Web remains a top priority
    ... Other items:
    ... API Minimization --- leave

    LM: Not clear this will make progress. Let us publish now.

    Dan: Maybe a new TAG member will have new energy to put in this
    ... I can come back with a proposal how to publish it

    Noah: We can leave open for a few weeks and then decide. Or decide
    to publish now.

    Dan: I will come back with a proposal for our next telcon

    Noah: HTML/XML Unification
    ... this is either done or we keep in this mode
    ... Persistence of Identifiers
    ... should we move this up in priority

    jar: Publishing a Workshop Report would be good.
    ... then i can do some writing based on yesterday's session

    <Yves> ACTION-622?

    <trackbot> ACTION-622 -- Noah Mendelsohn to schedule discussion of
    html.next as possible new TAG work focus (per Edinburgh F2F)
    [self-assigned] -- due 2011-12-20 -- PENDINGREVIEW

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

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

    <Yves> ACTION-652?

    <trackbot> ACTION-652 -- Yves Lafon to danA to come back with a
    proposal on API minimization draft -- due 2012-01-17 -- OPEN

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

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

    <noah> ACTION: Noah to schedule telcon discussion of Persistence
    product page (which was drafted for but not reviewed at F2F0 Due:
    2012-10-17 recorded in [52]http://www.w3.org/2012/01/05-tagmem-irc]

      [52] http://www.w3.org/2012/01/05-tagmem-irc

    <trackbot> Created ACTION-653 - Schedule telcon discussion of
    Persistence product page (which was drafted for but not reviewed at
    F2F0 Due: 2012-10-17 [on Noah Mendelsohn - due 2012-01-12].

    Noah: Microdata and RDFa
    ... is this done?

    JT: I think we should declare success
    ... I will write a final taskforce report and tell the TAG and the
    HTML WG

    <noah> ACTION: Jeni to write "product" page summarizing wrapup of
    RDFa/Microdata work Due: 2012-01-31 [recorded in
    [53]http://www.w3.org/2012/01/05-tagmem-irc]

      [53] http://www.w3.org/2012/01/05-tagmem-irc

    <trackbot> Created ACTION-654 - Write "product" page summarizing
    wrapup of RDFa/Microdata work Due: 2012-01-31 [on Jeni Tennison -
    due 2012-01-12].

    Noah: Web Apps Storage

    <JeniT> ScribeNick: JeniT

    noah: client-side local storage is not a spec

    ashok: the difficulty is there's more than one web storage
    capability

    (looking at draft
    [54]http://www.w3.org/2001/tag/products/clientsidestorage.html )

      [54] http://www.w3.org/2001/tag/products/clientsidestorage.html

    ashok: the success criteria look like requirements for a Web Storage
    Working Group

    noah: I'm trying to spell out good practice for people developing
    web apps, such as a calendaring application
    ... how to design a good web app

    TimBL: perhaps express it as a set of patterns
    ... when we did a top-down analysis of versioning, it didn't really
    work
    ... local storage is new, and it will change a lot soon
    ... there's a caching pattern when the URI on the web is used
    everywhere to refer to the document, even when it's in local storage

    noah: the TAG isn't committed to doing anything in this space at all
    currently
    ... what we need to do here is to decide how to scope it and choose
    where to invest

    larry: it's difficult to come up with best practices, but we could
    come up with criteria for evaluating a design
    ... we don't have to produce the patterns, just say how to evaluate
    a design

    ashok: evaluate on what basis? I thought using patterns or use cases
    would help

    noah: there are cases where we will have a good idea for a pattern,
    such as where the same information is stored locally and on web
    ... but then it's hard to point to local vs web
    ... we need a plan that's more than just noodling on use cases
    ... how about we refine this draft product page?

    larry: examining even one tradeoff is useful

    ashok: Dan, when could we have something about the workshop? do you
    have a draft?

    <noah> ACTION-523?

    <trackbot> ACTION-523 -- Ashok Malhotra to (with help from Noah)
    build good product page for client storage finding, identifying top
    questions to be answered on client side storage -- due 2011-12-20 --
    OPEN

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

      [55] http://www.w3.org/2001/tag/group/track/actions/523

    dan: there are minutes

    <DKA> Minutes for off-line web apps workshop:
    [56]http://www.w3.org/2011/11/05-offline-minutes.html

      [56] http://www.w3.org/2011/11/05-offline-minutes.html

    <noah> ACTION-523 Due 2012-01-17

    <trackbot> ACTION-523 (with help from Noah) build good product page
    for client storage finding, identifying top questions to be answered
    on client side storage due date now 2012-01-17

    <scribe> ScribeNick: Ashok

    Noah: I feel moderately good about the topics we have.

    JT: SPDY?

    Noah: Let's talk about this after tomorrow's session.

    <Norm> Norm begins by thanking Tim for the fine hospitality

    <Norm> Norm begins by thanking Tim again for the fine hospitality

XML/HTML Convergence

    <noah> ACTION-437?

    <trackbot> ACTION-437 -- Tim Berners-Lee to create a task force on
    XML / HTML convergence -- due 2011-06-01 -- CLOSED

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

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

    <Norm> => [58]http://www.w3.org/2010/html-xml/snapshot/

      [58] http://www.w3.org/2010/html-xml/snapshot/

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

      [59] http://www.w3.org/2001/tag/tag-weekly#htmlxml

    Noah: We should review the report, determine whether further action
    is required and update product pages, etc.

    Norm: My goal is to publish report, which the TAG needs to do so
    that we can get public review

    Noah: We could publish a note

    Norm: The TAG wanted a strong statement re. Polygot but there were
    people that thought that that was a waste of time
    ... so that does not appear
    ... I attempted to incorporate the feedback I got

    <jar> 2.1.1 in the table of contents

    <noah> [60]http://www.w3.org/2010/html-xml/snapshot/

      [60] http://www.w3.org/2010/html-xml/snapshot/

    <timbl> In the report please change "Resolution Broadly speaking,
    there are two techniques for addressing th" to "Resolution Broadly
    speaking, there are two alternative techniques for addressing th"

    LM: Add names of other contributers?

    Dan: Are editorial comments in scope?

    Norm: Yes, they are

    LM: I want references to source material

    Noah: Add sentence mentioning minutes of telcons

    s/mentioing/mentioning/

    LM: Cite [the] paper backing up the assertion that "much of HTML is
    generated".

    Norm: Could you identify where references would help?

    Dan: Re. last para ... sets out a false dichotomy
    ... should say "if you want to ... . you could use polyglot"
    ... use positive wording

    <JeniT> "Consumers that require polyglot markup will fail with
    content doesn't adhere to it. Therefore, consumers that want to
    access lots of random data can't use polyglot. On the other hand, in
    a constrained environment (eg where the consumer is publisher),
    polyglot is more viable"

    <jar> People who like this sort of thing will find it's the sort of
    thing they like. (re polyglot)

    Norm: There was some pushback re. polyglot

    Dan: If you have a corpus, you want to publish documents on the web
    [but] use it also as XML, you should use XHTML

    <jar> Polyglot reduces the number of versions you have to keep track
    of

    Noah: Multiple uses of documents

    Norm: If there is an angle for giving polyglot a better angle, I'm
    all for it, but the task force did not want that

    JT: We want to digitally sign the pages as XML

    <jar> LM: Just say there are use cases for polyglot the TF didn't
    consider and didn't make progress on.

    <jar> ?

    Norm: I will attempt to incorporate this info in 2.1 and see if the
    taskforce will [buy] off on it

    <Zakim> DKA, you wanted to question the wording of the polyglot
    markup paragraph.

    <JeniT> scribenick: JeniT

    ashok: laxer XML parsers seem interesting, and there should be more
    of a reference

    ndw: if you want that to happen, I think the TAG should recommend
    taking that forward

    noah: the conclusion of the TF was that it was unlikely to be
    effective in practice, because it wouldn't be adopted by people
    using XML now

    ndw: the draft doesn't say that, it was just that the TF wasn't the
    right body to do that

    <scribe> scribenick: ashok

    Norm: The taskforce did not think this was central to their concerns

    <Zakim> JeniT, you wanted to ask about HTML toolchains consuming XML

    Norm: We should charter a WG if we want this work to get done

    JT: Why bother discussing the usecase in 2.2?

    Norm: For balance ... I think it comes to the right conclusions

    Tim: What was the most hardest point?

    Norm: How to make XML more forgiving of errors

    (Discussion of how to make XML more forgiving of errors)

    Norm: The XML spec states it should be well formed

    Noah: Spec does not talk about errors and perhaps how to deal with
    them.

    Norm: My take away was -- just put an HTML parser in front. And that
    works.

    <Zakim> noah, you wanted to talk about where XML forgiveness is
    discussed

    Noah: The conclusion section should restate earlier material. So,
    ...

    <noah> Specifically, I noted that the sentence "However, it's
    entirely unclear that the XML community would be motivated to adopt
    such changes and, in any event, making such proposals is outside the
    scope of this Task Force." is in the conclusions only. That thought
    should also be in 2.5, I think.

    <noah> Norm agreed.

    jar: "HTML parser" is not defined ... perhaps use "standard HTML
    parser"

    Yves: It should be HTML5 Parser as it is the first spec to define
    parsing model

    jar: Rewrite for the naive user ... define terms

    Norm: Define HTML parser as something that conforms to HTML5 spec

    jar: In 2.2 can you make a stronger statement if input is XHTML

    Norm: It's likely to get XHTML right

    jar: It is worth saying that
    ... Does not discuss XSLT

    Norm: XSLT is a XML tool, not an HTML tool

    JT: Use XSLT to covert XML to HTML?
    ... the document says that

    jar: Says in 2.5 "the HTML parser", earlier it says "an HTML
    parser".

    <Zakim> JeniT, you wanted to ask about embedding XML islands in
    polyglot/XHTML

    Norm: Should always say "an HTML5 parser"

    Tim: Cannot substitue XML parser for HTML parser ... they produce
    different DOMs

    Norm: Eventually, there will be a single DOM

    <JeniT> JeniT: section 2.4 should mention (a) that you can embed any
    old XML in XHTML without <script> and (b) that you cannot use the
    <script> method in Polyglot markup

    Noah: There is a missing shim between XML and HTML DOMs

    Norm: There are several shims around

    (Discussion about differences in DOMs)

    <Zakim> masinter, you wanted to review comments

    LM: Editorial stuff re. comment should go to Task Force

    Norm: SOTD needs updating

    LM: There is ladder of comparisons, XML/HTML infosets etc.
    ... Asks about digital signatures ... cannot do it in HTML
    ... need to convert HTML to XML

    <jar> LM: what if you want to apply EXI to HTML?... want to know how
    to slot this (and other random use cases) into the document

    Norm: Document is clear about where it says XHTML and HTML
    ... no confusion there

    <jar> LM: no orientation to layered architecture - surface syntax,
    parse tree, element semantics

    LM: Should say why someone should care about this document

    Noah: Who is the audience for this?

    Norm: The intro says that.
    ... Technical folks on one side or the other interested in the issue

    <jar> LM: maybe the average AC member as audience

    Noah: Does this document do it for that audience?

    LM: Other audiences: Typical AC member, someone in the trade press

    <DKA> I think the document is fine for the Intended audience (modulo
    my earlier comments regarding polyglot).

    <jar> "Readers are encouraged to report additional use cases" -
    really? I thought you were trying to wrap this up

    Noah: The question is "Is it a useful piece of work for the audience
    it is intended for"

    (Discussion about different audiences)

    Noah: There is a wiki, right? Would that answer the question?

    Dan: This is useful for folks struggling with these problems

    Noah: Can we discuss next steps?

    Norm: It's going to be hard to get all the references ... this
    represents the judgements of a lot of smart people

    Tim: I support taking the document forward

    Ashok: Norm should react to the comments he has received and then we
    should vote whether to publish the document

    Noah: How shall we publish the document?

    Tim: Let's publish as a Finding and then a Note

    JT: Do you want public review?

    Norm: I would like to publish the draft as is as a Finding then fix
    it up and publish as a Note

    <jar> LM volunteers to write status section

    Noah: Does anybody object to publishing the document as a Draft
    Finding as soon as Norm makes the changes we recommended?

    Norm: I would like to have it published in some form

    DKA: Editorial changes should be incorporated

    Yves suggests a W3C Note

    scribe: Notes can be updated

    Yves: It was a product of a task force

    Tim: Gets it into the mainstream

    Feeling that Note is better

    Noah: Norm, pl. work with Yves to prepare a document to be published
    as a Note
    ... we can then review and then we can vote and publish

    RESOLUTION: The TAG thanks Norm Walsh and the task force, and
    expects that Norm will shortly provide the TAG for review a draft on
    XML/HTML Unification to be published as a W3C note for comunity
    review and comment. TAG chair will check with TAG before giving
    final clearance for publication.

    <DKA> +1

    LM: Change the name of the document?

    <noah> ACTION-587?

    <trackbot> ACTION-587 -- Jonathan Rees to prepare issue-57 and
    issue-63 documents for TAG members to discuss at Sept F2F -- due
    2011-10-11 -- CLOSED

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

      [61] http://www.w3.org/2001/tag/group/track/actions/587

    <noah> ACTION-591?

    <trackbot> ACTION-591 -- Noah Mendelsohn to ping Norm end of Sept.
    on revised HTML/XML report per discussion on 1 Sept 2011 -- due
    2011-12-27 -- PENDINGREVIEW

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

      [62] http://www.w3.org/2001/tag/group/track/actions/591

    Tim: The Taskforce stems from Raman's request for XML/HTML
    unification

    Noah: I will prepare a covering note, which I will share with you,
    which will have some of the history

    Norm: I prefer in the cover letter

    LM: Could be in the introduction

    Tim: I prefer the history in the cover letter

    <noah> ACTION: Noah to check Norm Walsh draft of W3C Note with the
    TAG, draft cover letter to include with Note, and review that with
    the TAG Due: 2012-01-17 [recorded in
    [63]http://www.w3.org/2012/01/05-tagmem-irc]

      [63] http://www.w3.org/2012/01/05-tagmem-irc

    <trackbot> Created ACTION-655 - Check Norm Walsh draft of W3C Note
    with the TAG, draft cover letter to include with Note, and review
    that with the TAG Due: 2012-01-17 [on Noah Mendelsohn - due
    2012-01-12].

    JT: Asks about taking the XML5 work forward

    <noah> JT: Two additional things we might do 1) possible
    encouragement of W3C to do something like XML5 on liberal XML
    processing 2) possibly do a new version of note that would better
    target needs of AC members, etc.

    <noah> ACTION: Noah to schedule discussion of possibly getting W3C
    to invest in technologies for liberal XML processing (e.g. XML5)
    recorded in [64]http://www.w3.org/2012/01/05-tagmem-irc]

      [64] http://www.w3.org/2012/01/05-tagmem-irc

    <trackbot> Created ACTION-656 - Schedule discussion of possibly
    getting W3C to invest in technologies for liberal XML processing
    (e.g. XML5) [on Noah Mendelsohn - due 2012-01-12].

    <noah> NW: XML Prague is weekend of 11th and 12th of February (Jeni
    is keynoting on Microdata and RDFa)

    <noah> NW: Anne will present XML5. Robin Berjon had some ideas for
    the task force, and he will present those. Norm is chairing a panel
    on XML/HTML.

    <Norm> => [65]http://www.xmlprague.cz/2011/sessions.html

      [65] http://www.xmlprague.cz/2011/sessions.html

    <noah> ACTION: Noah to schedule telcon discussion of possible
    XML/HTML Unification next steps Due: 2012-01-27 [recorded in
    [66]http://www.w3.org/2012/01/05-tagmem-irc]

      [66] http://www.w3.org/2012/01/05-tagmem-irc

    <trackbot> Created ACTION-657 - Schedule telcon discussion of
    possible XML/HTML Unification next steps Due: 2012-01-27 [on Noah
    Mendelsohn - due 2012-01-12].

    <JeniT> [67]http://www.xmlprague.cz/2012/sessions.html

      [67] http://www.xmlprague.cz/2012/sessions.html

    <Norm> => [68]http://www.xmlprague.cz/2012/sessions.html

      [68] http://www.xmlprague.cz/2012/sessions.html

    <noah> ACTION-657 Due 2012-01-17

    <trackbot> ACTION-657 Schedule telcon discussion of possible
    XML/HTML Unification next steps Due: 2012-01-27 due date now
    2012-01-17

    <jar> scribe: Jonathan Rees, Ashok Mahotra

Summary of Action Items

    [NEW] ACTION: Jeni to write "product" page summarizing wrapup of
    RDFa/Microdata work Due: 2012-01-31 [recorded in
    [69]http://www.w3.org/2012/01/05-tagmem-irc]
    [NEW] ACTION: Noah to announce closing of Web App State Product Due:
    2012-01-17 recorded in [70]http://www.w3.org/2012/01/05-tagmem-irc]
    [NEW] ACTION: Noah to check Norm Walsh draft of W3C Note with the
    TAG, draft cover letter to include with Note, and review that with
    the TAG Due: 2012-01-17 [recorded in
    [71]http://www.w3.org/2012/01/05-tagmem-irc]
    [NEW] ACTION: Noah to schedule discussion of possibly getting W3C to
    invest in technologies for liberal XML processing (e.g. XML5)
    recorded in [72]http://www.w3.org/2012/01/05-tagmem-irc]
    [NEW] ACTION: Noah to schedule telcon discussion of Persistence
    product page (which was drafted for but not reviewed at F2F0 Due:
    2012-10-17 recorded in [73]http://www.w3.org/2012/01/05-tagmem-irc]
    [NEW] ACTION: Noah to schedule telcon discussion of possible
    XML/HTML Unification next steps Due: 2012-01-27 [recorded in
    [74]http://www.w3.org/2012/01/05-tagmem-irc]

      [69] http://www.w3.org/2012/01/05-tagmem-irc
      [70] http://www.w3.org/2012/01/05-tagmem-irc
      [71] http://www.w3.org/2012/01/05-tagmem-irc
      [72] http://www.w3.org/2012/01/05-tagmem-irc
      [73] http://www.w3.org/2012/01/05-tagmem-irc
      [74] http://www.w3.org/2012/01/05-tagmem-irc

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [75]scribe.perl version 1.135
     ([76]CVS log)
     $Date: 2012/01/14 00:50:29 $

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


================== 6 January 2012 =====================

    [1]W3C

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

                                - DRAFT -

               Technical Architecture Group Teleconference

06 Jan 2012

    See also: [2]IRC log

       [2] http://www.w3.org/2012/01/06-tagmem-irc

Attendees

    Present
           Dan Appelquist, Jonathan Rees, Ashok Malhotra, Noah
           Mendelsohn, Larry Masinter, Tim Berners-Lee, Yves Lafon,
           Peter Linss, Mark Nottingham (invited guest for morning
           session)

    Regrets
           Henry Thompson

    Chair
           Noah Mendelsohn

    Scribe
           Jeni, Dan

Contents

      * [3]Topics
          1. [4]Mime and the Web (with Mark Nottingham)
          2. [5]Web protocols: HTTP Futures & SPDY (with Mark
             Nottingham)
          3. [6]Redirection semantics
          4. [7]Redirection of POST and User Intervention
          5. [8]Identifier Overloading
          6. [9]Issues for Jeff
          7. [10]Action Item Review
          8. [11]CA Issue
      * [12]Summary of Action Items
      _________________________________________________________

Mime and the Web (with Mark Nottingham)

    (introductions)

    mnot: chairing HTTPbis, liaison from IETF to W3C
    ... "Web Linking" spec is an attempt to respecify Link: header
    ... lots of requirements for link-based protocols
    ... and typed links
    ... for example in HTML rel="stylesheet"
    ... Atom used link relations as well
    ... and there's a registry and an XML syntax for links and link
    relations
    ... eg copyright statements, next/previous links
    ... wanted to revive Link: HTTP header
    ... to convey links in headers rather than body of the message
    ... HTML had linking, Atom had linking, and they weren't matched
    ... RFC provides a model that you can serialise in various ways
    ... needs a context, a type, and a target
    ... (which you could map to RDF if you wanted to)

    jar: is that called out anywhere?

    mnot: not particularly
    ... and so to registration
    ... link types being a particular example
    ... we felt there should be one registry
    ... the HTML groups wanted to use a wiki
    ... we felt that was too freeform, and noisy
    ... and could lead to changing semantics in a backwards-incompatible
    way
    ... so we tried to address their concerns in the registry
    ... but they (the HTML group) didn't feel it was an appropriate
    thing to use
    ... time passes
    ... the link relation registry is a lot of work to maintain
    ... every interaction requires discussion with the author

    noah: the overhead is high but the rate isn't high

    <timbl>
    [13]http://www.iana.org/assignments/link-relations/link-relations.xm
    l

      [13] http://www.iana.org/assignments/link-relations/link-relations.xml

    mnot: we would like to see a higher rate, but can't support it at
    that overhead

    jar: this is the same issue in journal publication

    mnot: the question is whether value is being added
    ... we have a common system of expert review in IETF
    ... the underlying question is what is registry for?
    ... some people see it as a gating function: if it's not registered,
    then it won't be used
    ... to prevent stuff that is bad from being used
    ... but the gating function makes people less likely to use the
    registry

    noah: so people go ahead and do it anyway, without using the
    registry

    mnot: we discovered this was common to registries for media types,
    link relations, HTTP headers and URI schemes
    ... talked to Ned Freed
    ... who runs the media type registry
    ... saw that people were misinterpreting the function of registries
    ... actually the registry should reflect what is in use

    noah: is there a middle ground?

    mnot: for a lot of people, registry is just a barrier to get past
    ... especially because the work is all up-front

    noah: no one says they would deploy more quickly if it was
    registered

    mnot: there's no benefit in the registration

    masinter: it just exposes you to criticism

    timbl: text/n3 is an example for me
    ... the best practice was to use Turtle, but people would use
    application/rdf+xml because it was registered

    mnot: people who pay attention to standards might care

    timbl: getting media types into Apache does have a big effect

    mnot: Apache put lots of stuff in, it's driven by the market

    timbl: So Apache mime .types works and iana doesn't -- why doens't
    IANA use the same process as Apache?

    mnot: we want to create a virtuous cycle, for example with
    machine-readable registry data
    ... for example for link relations that lets you add attributes to
    registry entries
    ... so that a browser can see whether it's a link that could be
    followed
    ... or archived and so on
    ... so if I come up with a new link relation, and it's treated in a
    generic way
    ... the browsers can have a more automated process for adding
    semantics

    noah: we have to give Jeff Jaffe early warning about potential
    larger issues
    ... it seems that there's a bigger story here about market forces
    driving standards

    mnot: what we want to do is make IANA a suitable place for these
    registries
    ... which is complex, but worth trying

    <Zakim> JeniT, you wanted to ask whether browsers will really pick
    up on this metadata automatically

    <JT:/cite>> You spoke of browsers automatically going to registries
    and doing something useful with what they find. Do you have actual
    experience with people being willing to do that? I haven't seen it
    in my work on RDF.

    <mnot:> My understanding is that Ian Hickson and Anne van Kesteren
    felt this would be very helpful in the registries

    <mnot:> I think one aspect of the value is during the browser
    development and QA process, where those building a browser can pull
    from the central registry, do some work to integrate with their
    browser or tests, and then deploy.

    <larry:> It's almost as if you want to have so much in the IANA
    registry that you would never want to use it real time.

    <mnot:> Hmm. Probably if you do things real time there will be
    attack vectors.

    <HTJT:cite>> And the process for staying in sync is to do a pull
    every time they release the browser.

    <mnot:> Yes, but they are on very quick update cycles now

    <mnot:> Seems unlikely we'll see people automatically supporting new
    media type handlers.

    <Larry:> I think I've seen things where apps on phones can register
    for URI prefixes

    noah: has anyone looked at associating some a Javascript handler
    with eg a link relation
    ... which the browser could then use to handle likes of those types

    mnot: that's a bit speculative
    ... we want to focus on a virtuous cycle where code can use the
    information in the registry

    timbl: ontologies are like this

    mnot: the registry needs to reflect what's in use, not how things
    should be
    ... you need to make the barrier to entry low
    ... and iteration rapid
    ... to incrementally improve the entry

    noah: it sounds like you're going very far over to there being no
    barriers
    ... towards something completely open like a wiki
    ... I think it's more a shift towards that rather than going
    completely to the extreme

    mnot: the problem is that expert reviewers have a tendancy to try to
    maintain quality and prevent new entries going in

    mastinter: registries have rows and columns
    ... there's a column with 'review status' which people making the
    entry can't change
    ... which can be 'unreviewed' or 'unacceptable'

    <noah> Philippe le Hegaret joins us in the meeting room

    mnot: yes, we've talked about having a range of statuses
    ... it comes down to having a process to manage the registry
    ... if you have a wiki, that's going to happen because there are
    going to be conflicts within the community
    ... and there will be cases where you can't tell what to do, where
    there are two implementations using the same name with different
    semantics

    <mnot> [14]http://www.w3.org/wiki/FriendlyRegistries

      [14] http://www.w3.org/wiki/FriendlyRegistries

    mnot: so we started having meetings within IETF, and have set up a
    mailing list
    ... FriendlyRegistryProcess
    ... for example, turning the expert reviewer into more of a
    community moderator than a gatekeeper
    ... for example, Apple is using a bunch of URI schemes which aren't
    currently in the registry

    noah: should one size fit all?
    ... it might be different for URI schemes than for link relations
    ... it might be that it has different technical consequences to
    introduce new URI schemes

    timbl: there should be very few URI schemes added, but a larger
    number of media types
    ... because that's how the system is designed
    ... about switching to a model where you register what exists
    ... that does avoid conflict
    ... I would support a very open bug tracking system on the registry
    ... suppose someone registers something, and that automatically
    opens up a bug tracker for them, so people could make comments on it

    mnot: yes, we talked about this

    timbl: not for the process of the registration, but to register
    technical issues

    mnot: we talked about having a wiki page for each entry
    ... there's a hidden bug tracker for IANA

    timbl: tracker for issues about the entry

    mnot: we do want to support third parties to register protocol
    elements
    ... so if a company hasn't registered something, others can do it
    instead

    timbl: ideally you want that to go through very fast, so that there
    can be feedback on the entry

    mnot: and that comes back to the different statuses on the entries
    ... to label that something has technical or legal issues
    ... we want to order the entries to make the good ones more
    prominent

    (moving on to next steps)

    mnot: we've had some discussions on this within IETF for the last
    year or so
    ... Ned is doing a revision of [some RFC]
    ... and revisions of link relations RFCs
    ... and the message header registries RFCs
    ... and another document to distil this discussion into "how to set
    up a registry"

    masinter: I have done some work on that

    mnot: there are things that IANA can do without updating RFCs

    jar: are they cooperative?

    <masinter> in
    [15]http://www.w3.org/2001/tag/2011/12/evolution/Registries.html

      [15] http://www.w3.org/2001/tag/2011/12/evolution/Registries.html

    mnot: yes, they need the IETF to take the initiative and they are
    resource constrained
    ... and we've talked about having Wiki pages for each entry
    ... this is a long term project
    ... the mailing list is the main contact place
    ... I am the main contact

    masinter: a little W3C resource would make things go a lot faster

    <Yves>
    [16]https://www.ietf.org/mail-archive/web/happiana/current/maillist.
    html

      [16] https://www.ietf.org/mail-archive/web/happiana/current/maillist.html

    <noah> [17]https://www.ietf.org/mailman/listinfo/happiana

      [17] https://www.ietf.org/mailman/listinfo/happiana

    timbl: is anyone within the TAG following it?

    yves: I am on the mailing list

    masinter: I am as well

    noah: I'm assuming Larry is our point person on this

    masinter: I need help
    ... I haven't been able to write this up in a way that was
    understood
    ... we need some resources to make some things happen
    ... and I don't know how to actually make this happen

    noah: what aspects of this should be done within the TAG?
    ... perhaps we could just free up some of Larry's time to work on
    it?

    mnot: we would appreciate your review of what we have written up on
    the wiki

    noah: so we should have one or two TAG members review it and frame a
    way forward

    timbl: we can register our enthusiasm and encouragement

    <masinter> the main problem i see is that current and previous TAG
    findings might be in conflict with the new directions being pursued,
    and that the TAG is more of a bottleneck than a group that can help.

    timbl: on TAG ground, each registry is a piece of the architecture
    of the web
    ... the TAG could dive into how much damage there is when someone
    makes a new URI scheme

    <masinter> i prepared some material on this subject in the slides i
    put together for this meeting and was unable to get agenda time to
    present it

    noah: arguably it's not a registry discussion

    timbl: for a given registry, the TAG might want to point out the
    damage done by a badly designed scheme

    mnot: so long as that doesn't prevent entries going into the
    registry
    ... even if the bad ones are highlighted with blinking 'Evil' icons

    noah: should we actually do this (about URI schemes)
    ... is there any new work that we should kick off now?
    ... also, does it help to have a formal TAG resolution to support
    this work?

    mnot: probably not now, I just wanted to socialise this with you

    noah: we're very interested in this, and we have been looking at
    this in an ongoing way, and we will keep on doing so

Web protocols: HTTP Futures & SPDY (with Mark Nottingham)

    noah: a few months ago, it started to look as though SPDY was
    expanding beyond Google
    ... we had a technical discussion at TPAC 2011
    ... it looks like there could be major changes to the web due to
    innovations such as SPDY
    ... doing everything through SSL

    mnot: the SPDY guys have strong dislike for transparent protocols
    (?)

    noah: and there's a privacy angle here
    ... we haven't for a while looked at this level of web architecture
    ... we want to decide if this is an area where the TAG needs to do
    serious work, what the goals are, who is going to do it
    ... and top priority is to have discussion with Mark
    ... we could look at Yves email
    [18]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html
    ... to which there were some responses

      [18] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html

    mnot: I would like to talk for 10 minutes and then have discussion

    mnot: we started HTTPbis about 4 years ago
    ... the idea was to revise HTTP because we now had 10 years of
    implementation experience of RFC2616
    ... there was a lot of knowledge locked up in people's heads that we
    wanted to get written down
    ... with quite a tight charter
    ... not a new version of HTTP, no extensions, just fixing the specs
    ... we're almost done
    ... we have about 11 design tickets open, many of those will be
    closed really soon
    ... the editors are Yves, Roy Fielding and Julian Reschke
    ... we wanted to make something solid for 10-20 years
    ... meanwhile implementers have come up with SPDY, mostly for
    performance
    ... addressing a number of issues with HTTP and its serialisation
    over TCP (?)
    ... the Google guys have an implementation, both server and client
    ... Patrick McManus has done implementation in Firefox, also HTTP
    pipelining
    ... he's found it easier to do SPDY than HTTP pipelining
    ... it should be in Firefox 11

    timbl: so it hasn't actually gone to market

    yves: Opera also provided feedback on pipelining

    mnot: the main problem with pipelining is that you have to use a lot
    of heuristics about when you can use pipelining
    ... within pipelining, requests can block

    noah: but in SPDY, you can interleave?

    mnot: yes
    ... Mike probably also covered Jim Getty's concerns about buffer
    bloat
    ... I did an implementation of HTTP pipelining and SPDY in Python,
    and SPDY was much simpler
    ... Amazon is using SPDY in the Kindle now, or are in process of
    doing so
    ... Daniel Stenburg, behind curl, is implementing a C library for
    SPDY

    noah: in Amazon Fire, there's the split browser, do they also use
    SPDY in requests out to the wider web?

    mnot: I'm not sure
    ... Google is practically the only server implementation
    ... GenX has just announced implementation too
    ... I noticed this momentum a couple of months ago
    ... it's not just Google any more
    ... I've had a lot of private discussions with various people, and
    everyone is very very interested in tracking/implementing this stuff
    ... the market is choosing with its feet
    ... the question is whether this gets done within a standards
    organisation, with interactions with other implementers than Google
    ... it seems like it's necessary to take this work on

    noah: we asked Mike how he felt about that, and he seemed to be keen
    on standardisation

    mnot: we've had an ongoing discussion about standardisation
    ... the team understands it will involve
    ... there's a tension between getting to market and for everyone
    else to have their concerns met
    ... I've been talking to people about this and putting together a
    proposed charter for this work
    ... HTTPbis is just finishing up, and I don't want to distract from
    that
    ... but time is important for the SPDY guys too
    ... I've been talking about rechartering the HTTPbis group to work
    on HTTP evolution
    ... perhaps not saying that we should start from SPDY
    ... Roy has been working on WAKA (?)
    ... but it's not been made public
    ... looking at that and SPDY, I think they are conceptually very
    close
    ... continuing the HTTP 1.1 revision
    ... we have split up HTTPbis into components
    ... SPDY only requires changes in one of those components
    ... Part 1 of HTTPbis

    timbl: what's SPDY's relationship to HTTP headers

    mnot: it compresses them, but it uses the HTTP headers
    ... there are some headers that aren't needed in SPDY
    ... I used the same API as for HTTP when I did SPDY implementation
    ... there might be other tweaks, but SPDY would be a superset

    noah: SPDY would multiplex on one connection rather than having
    multiple connections

    timbl: people have assumed HTTP would be replaced in the future
    ... and therefore HTTP URIs would be replaced by other things
    ... but the HTTP namespace can be persistent even if the protocol
    works
    ... calling it HTTP 2 might be useful to avoid that confusion

    mnot: questions about spdy: URIs have always been resisted

    noah: there's an interaction with HTTPS and TLS and certificates
    ... there are differences between http: and https: URIs, https: uses
    certificates and http: don't

    mnot: there's a set of issues around TLS, about whether the CAs are
    a good source of truth

    noah: how far has the discussion gone?

    mnot: core people in SPDY feel that using TLS by default would
    improve the web
    ... other people don't agree

    noah: there are a bunch of issues with TLS, one of which is to do
    with name resolution
    ... it means I have to get a certificate for my server

    mnot: right now SPDY says you will deploy over TLS

    timbl: what about certificates from DNS Sec?

    mnot: there's a bunch of work on that, yes
    ... which sometimes gets governments involved
    ... the question is whether we can leverage it in time for SPDY
    ... in the IETF people are uncomfortable with the 'S' in 'HTTPS'
    ... that there shouldn't be a flag in the URI that indicates
    security
    ... but the browser people like it
    ... the concept of the origin server means having 'S' is really
    useful

    timbl: but you may want to add more constraints, not just the 'S'
    bit

    mnot: the question is about whether you should have it in the
    identifier

    timbl: in RDF it's a real pain
    ... moving to HTTPS wreaks havoc with links
    ... I've wondered about using POWDER to put a label on the home page
    ... to say that anything that starts 'https' should have the same
    identity as if you had 'http'
    ... like a canonical link

    mnot: I have a format for describing canonical URIs for a domain
    ... but this is a real tangent

    plinss: my understanding is that TLS and SPDY are orthogonal

    mnot: the way it's currently defined, TLS and SPDY are bundled
    ... I think there are cases where you don't want to use it

    masinter: if you start with a HTTP URL, does it use SPDY?

    mnot: it will upgrade the connection
    ... for an HTTPS URI, there's another negotiation

    noah: Google is using SPDY by default for HTTPS URIs

    mnot: using TLS NPN is an uncontroversial use
    ... OpenSSL isn't going to support it until the next version

    noah: how does this affect CDNs such as Akamai?

    mnot: they will need to support it
    ... it used to be hard because you need an IP per certificate
    ... now there's TLS SNI extension (?) but it's not perfectly
    deployed
    ... which is the Host header for TLS
    ... so that you can have 100 hostnames on one IP address

    noah: how does the HTTPS work through something like Akamai?

    mnot: they will need to know your private key or generate one for
    you
    ... one of the metrics of a tracker is rapid changing of
    certificates
    ... back to the charter
    ... the new bit is working on HTTP 2.0 with the goal of improving
    performance
    ... more efficient use of network resources
    ... deployment on today's internet, using IPv4 and IPv6
    ... maintaining ease of deployment
    ... and balancing that with reflecting modern security requirements
    ... there's a new requirement in IETF, any protocol has to have
    "mandatory to implement security"
    ... it has to have an adequate security mechanism that
    implementations must support
    ... the idea is to recharter the working group
    ... starting work around end of March
    ... which means HTTPbis needs to have been substantially done by
    then
    ... I'm hoping the HTTPbis review will be fairly straightforward
    ... because it's already gone through so much review
    ... particularly because we're not introducing new things
    ... we would put out a call for proposals for a starting point, one
    of which will be SPDY
    ... there's a lot of running code out there for SPDY
    ... the obvious question is why recharter the HTTP WG to do this,
    rather than creating a new one?
    ... I think it's worthwhile because we have a good working pattern
    and an established community
    ... we've talked about Mike Belshe and Julian Reschke being editors
    on the spec

    timbl: the WG might have to be warned about being open to new people

    mnot: we have almost complete coverage of HTTP implementers
    ... this needs to be a worthy replacement for HTTP 1.1
    ... we've got firewall, client, library, intermediary, embedded guys
    ... if I can't get it through, we'll charter a separate WG
    ... this is obviously of interest and importance to the TAG

    DKA: in naming it HTTP 2.0, isn't there a danger that the scope gets
    expanded?

    mnot: yes, we've dealt with that in HTTPbis
    ... and the charter is written in a focused way
    ... to prevent that

    <masinter>
    [19]http://masinter.blogspot.com/2011/12/http-status-cat-418-i-teapo
    t.html

      [19] 
http://masinter.blogspot.com/2011/12/http-status-cat-418-i-teapot.html

    timbl: looks good....

    … I think it's good to bring it out under a http 2.0 banner -

    <Zakim> timbl, you wanted to ask about the extensibility point of
    HTTP headers in SPDY

    … I think the fine line between directly taking on board existing
    work and allowing people to make arbitrary changes to existing work
    that runs is one I understand...

    jar: Jim Gettys gave us a presentation on buffer bloat, and I
    wondered how this related
    ... is this radical enough?
    ... he was talking about self-authenticating content and things

    mnot: this enables a solution to buffer bloat
    ... it will use TCP better
    ... particularly when people pull content back onto single domains
    rather than sharding
    ... right now the interest is in maintaining the client/server model

    noah: I think Jim spoke sympathetically about SPDY

    timbl: back to the HTTP level, I've been trying to push rather than
    a content-addressable system, you might be able to go back to the
    referer of a link to get information

    <masinter> there's a possibility that the two go together: SPDY for
    interactive, dynamic, personal, private traffic, and content
    addressible networking for public, cachable, distributed content.

    timbl: for example, to bootstrap into a peer-to-peer system

    mnot: have you seen Metalink?
    ... a new link relation called 'duplicate'

    mnot: an exact byte-for-byte duplicate for a given representation

    <masinter> [20]http://tools.ietf.org/html/rfc5854

      [20] http://tools.ietf.org/html/rfc5854

    timbl: the idea is to cache everything you link to to two levels

    mnot: there's a lot of interesting things to do in caching
    ... the quality of cache implementations is something that bothers
    me

    <masinter> pursuing both simultaneously would mean you wouldn't have
    to rely on caching

    mnot: I'm concerned around the parallel tracks of caching, for
    example with AppCache

    timbl: caches tend to be temporary; this idea is a mutual-aid system

    <masinter> wonder if some of hte weaker parts of HTTP could be left
    behind

    timbl: you'd build it into Apache and the client, and you'd be able
    to get data from parts of the network that were cut off

    masinter: there's lots of HTTP that isn't very good, that you could
    leave behind if you're not encapsulating all of HTTP
    ... and others that you could promote
    ... for example caching based on time stamps vs on ETags
    ... also HTTP uses the same transport for dynamic, private,
    interactive content as for large, public, static content
    ... right now we use Vary headers to distinguish between them
    ... maybe there's some other way that would be more reliable

    mnot: I'm nervous about that, because how far do you go? we don't
    want two separate protocols really

    masinter: you only split things off when they really don't fit

    mnot: I'm not convinced they don't fit

    noah: you can use a new URI scheme, that requires an early
    commitment

    DKA: do you know of any mobile implementations of SPDY?

    mnot: I don't know of any, but it looks like a tempting target for
    mobile, because the connection is used more efficiently
    ... it looks like a real win, and you can use SPDY in the proxy

    noah: what about battery drain on doing encryption?

    <masinter> look at SPDY android

    mnot: people claim TLS is not that hard; it depends on cipher
    strength
    ... I consider TLS and wire protocols to be separate

    DKA: the major battery drain aside from the display is usually the
    radio

    noah: I propose that this is put on the alert list for Jeff
    ... it sounds as if the right people are working on this in the
    IETF, but I can't see that we need to parachute in
    ... I think we should have a contact point in the TAG, and monitor
    progress

    mnot: I would add that this is likely to be discussed at Paris in
    late March

    noah: Yves, you've traditionally had actions on this

    yves: I will follow this for W3C anyway

    <noah> close ACTION-640?

    <noah> close ACTION-640

    <trackbot> ACTION-640 Frame F2F discussion of SPDY/HTTP futures
    closed

    yves: my email also touched on WebSocket
    ... most of the communication on that won't use URIs

    <noah> ACTION: Yves to prepare telcon discussion of protocol-related
    issues, e.g. Websockets/hybi (but not SPDY)Due: 2012-02-21 [recorded
    in [21]http://www.w3.org/2012/01/06-tagmem-minutes.html#action01]

      [21] http://www.w3.org/2012/01/06-tagmem-minutes.html#action01

    <trackbot> Created ACTION-658 - Prepare telcon discussion of
    protocol-related issues, e.g. Websockets/hybi (but not SPDY)Due:
    2012-02-21 [on Yves Lafon - due 2012-01-13].

    <noah> ACTION: Yves to track IETF efforts on HTTP 2.0 & SPDY Due:
    2012-03-20 [recorded in
    [22]http://www.w3.org/2012/01/06-tagmem-minutes.html#action02]

      [22] http://www.w3.org/2012/01/06-tagmem-minutes.html#action02

    <trackbot> Created ACTION-659 - Track IETF efforts on HTTP 2.0 &
    SPDY Due: 2012-03-20 [on Yves Lafon - due 2012-01-13].

    noah: we need to talk about things for Jeff

    <mnot> [23]https://datatracker.ietf.org/wg/dane/charter/

      [23] https://datatracker.ietf.org/wg/dane/charter/

    noah: CA system
    ... perhaps other security aspects
    ... perhaps how to deal with the TAG issues
    ... action item review

    <masinter> you might want to also look at the long list of dead TAG
    findings

Redirection semantics

    <masinter> [24]http://www.w3.org/2001/tag/findings

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

    mnot: issue with fragment identifiers and redirections

    <masinter> and also "Approved findings" we no longer believe in

    mnot: HTTP doesn't say which one gets precedence
    ... we talked with you and at the time we said, 'there's not good
    interop here'
    ... so didn't say what to do
    ... we didn't cover when the request has a fragid and the redirect
    location doesn't
    ... since then, we've tested implementations
    ... and there is good interop
    ... from a webarch standpoint would the TAG be concerned if the
    combination of fragid and redirect were determined by HTTP rather
    than media type dependent?

    noah: ht might have input on this

    mnot: we need an answer soon because we want it in HTTPbis
    ... my opinion is that from an implementation standpoint it is bad
    to make it media type dependent

    <noah> noah: would it be convenient for you to send an e-mail asking
    the TAG to consider this question? If so, i'll use that to trigger
    telcon discussion.

    <noah> mnot: Fine, no problem, I'll send the note.

    mnot: making it the same for everything is significantly less
    complex

    <noah> Recent TAG finding on fragment identifiers in Web
    Applications
    [25]http://www.w3.org/2001/tag/doc/IdentifyingApplicationState

      [25] http://www.w3.org/2001/tag/doc/IdentifyingApplicationState

    timbl: this is deeply connected with how the Semantic Web / Linked
    Data worked
    ... to me it was a shock that you could redirect to something with a
    fragid in it
    ... how common is it to have that kind of redirection?

    jar: Dublin Core

    <mnot> HTTPbis bug:
    [26]http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295

      [26] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295

    plinss: I think this is going to become more common as you have
    fragments on video/audio

    jar: URL shorteners

    timbl: do you have RDF test cases?

    mnot: no
    ... there's strong interop amongst the implementations we've checked

    timbl: adding the fragid to the redirected URI isn't a problem

    jar: +1
    ... I think it's implied by RFC3986

    masinter: one way or the other it has to be made explicit

    mnot: I'll send noah an email and we'll take it forward

    jar: I weighed in on this before and didn't get any reaction

    <noah>
    [27]http://www.w3.org/2001/tag/doc/IdentifyingApplicationState

      [27] http://www.w3.org/2001/tag/doc/IdentifyingApplicationState

    noah: the TAG did quite a bit of work in the last year on web
    application state and fragid semantics
    ... that might be of interest

    <mnot> [28]http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238

      [28] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238

Redirection of POST and User Intervention

    mnot: most of the browsers redirect automatically
    ... because the users don't know whether it's safe to redirect
    across domains
    ... so perhaps we should remove that requirement from HTTP
    ... but it's a fairly big change
    ... but it doesn't reflect reality

    timbl: has anyone suggested any improvement?
    ... currently this is a fairly huge hole

    mnot: there are so many ways to generate requests to multiple hosts
    in browsers
    ... they are moving away from making security visible
    ... because it doesn't meaningfully improve security

    timbl: so it's a cross-domain issue?

    mnot: we could phrase the requirement be about cross-domain
    redirects

    <jar> n.b. the discussion is of 301 redirects specifically (with
    unsafe methods such as POST)

    mnot: we can't make incompatible changes in HTTPbis unless it's a
    serious security issue
    ... and this isn't serious
    ... right now this applies same-domain

    timbl: relaxing it for same-origin makes sense

    mnot: one browser prompts in a couple of specific situations
    ... but most already ignore the requirement

Identifier Overloading

    mnot: Sec- prefix on HTTP headers
    ... adding semantics to an identifier brings problems
    ... how do you add more prefixes?
    ... X- for experimental, then it gets adopted
    ... (that is close to deprecated)

    noah: how you support decentralised extensibility + smooth evolution
    from experimental to common is something the TAG could look at
    ... I'm not sure we can do that well in the TAG

    mnot: we're covering it a bit in happiana

    jar: registries, decentralised extensibility and persistent naming
    are all closely related

    noah: it's more about whether the community can see progress

    (wrapup)

    Minutes integration: Wednesday : Yves ; Thursday: JAR ; Friday : Dan

    <JeniT> "we need to talk about things for Jeff

    <JeniT> CA system

    <JeniT> perhaps other security aspects

    <JeniT> perhaps how to deal with the TAG issues

Issues for Jeff

    Noah: Jeff has asked the TAG to alert him to big controversies and
    threats to the Web that he might not know about.

    … I have ACTION-568.

    <noah> ACTION-568?

    <trackbot> ACTION-568 -- Noah Mendelsohn to draft note for Jeff
    Jaffe listing 5 top TAG priorities as trackable items. -- due
    2012-01-03 -- OPEN

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

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

    … We are overdue on this action.

    … We need a plan that will close in a few days for an initial note
    to Jeff.

    … This says "5" but I don't think 5 is a magic number.

    Yves: 20 items is too many.

    Noah: Let's see what we have.

    <Yves>
    [30]https://lists.w3.org/Archives/Member/tag/2012Jan/0001.html

      [30] https://lists.w3.org/Archives/Member/tag/2012Jan/0001.html

    Noah: [outlines above list]

    [discussion on death of protocols]

    Yves: this is the list discussed during f2f in Edinburgh.

    Noah: two more - one is a think Dan asked for: should app cache vs
    app packaging be on the heads-up list for Jeff?

    … Noah: I think the only reason to highlight this is if it's not
    adequately highlighted in the workshop report.

    Dan: risk is more generally apps vs web.

    Jenit: which we already have.

    Ashok: [asks for clarification]

    Noah: We need descriptions of threats or potential threads to send
    to Jeff - between a paragraph and a short page.
    ... if people like the list, let's look at each one.

    JeniT: should the registries and IANA stuff get moved into the
    bigger section?

    … especially rdfa vs html link relations.

    Yves: this is not new.

    … if there will be more issues based on this - e.g. registries being
    misused - then yes.

    Noah: If we think e.g. Happiana will rise into a key issue then we
    might raise it to Jeff.

    … we could make it an addendum to the main list.

    Yves: "there have been issues - there will probably be more issues -
    there is this work happening (IANA)"

    JAR: … and a small effort by w3c staff could help.

    Noah: Jeff asked me for [major issues] that might hit him.

    JeniT: Along those lines, the section on SPDY and http - this feels
    less like something that we need to be mega-concerned about.

    Noah: I think http is a major part of the Web - we should [outline
    the key topics] and then say "we have been working with e.g. mnot
    about it and this is what's happening..."
    ... let's go through the things Yves has drafted on each of these.
    ... first - "Specifications with the Same Scope…"
    ... Question I would ask - you talk about RDFa

    Yves: With the evolution of different stacks, they step on other
    technology stacks' feet. It's difficult to predict that.

    Noah: If we know of anything similar to microdata/rdfa then we
    should alert Jeff.

    Yves: another one might be xpath and css selectors.

    Noah: is that resolving?

    Yves: I think it's more or less under control.

    JeniT: We can say - following discussion with plh over html.next
    there seem to be areas e.g. speech but our advice from him was that
    this wasn't going to cause problems.

    <noah> I think we need to tell Jeff where the ones we know about
    stand, and where there are others that are likely to be problems. I
    hear Yves saying: microdata/RDFa and CSS/XPath are probably headed
    for resolution, but these things will keep happening.

    … the two things that could be hot topics look like they are being
    handled in the right way.

    Noah: I think this should come out under my signature on behalf of
    the TAG.

    … I feel sufficiently informed on this one to take a cut.

    <noah> Current draft: The TAG, as part of its review activity will
    continue to monitor such

    <noah> issues.

    <noah> Suggested: The TAG, as part of its review activity will
    continue to monitor such

    <noah> issues.

    Yves: last para where I said TAG is reviewing what is going on -
    even if we don't know an issue that will happen in the next 6
    months, in 2 months we might discover an issue.

    <noah> issues and we will alert you to any that we think are of
    particular concern.

    Noah: Next one - "phone apps vs web apps"

    yves: there are a range of issues here, and I'm not sure what the
    crux is

    <noah> YL: On the mobile, I'm not sure where the issues are.

    DKA: there's things like URI schemes as well

    <noah> DKA: It touches on things like vendor-specific URIs

    DKA: and the "death of the web"

    noah: can you send me an email?

    <noah> ACTION: Dan to put together a bulleted list of items to go
    into this category [recorded in
    [31]http://www.w3.org/2012/01/06-tagmem-minutes.html#action03]

      [31] http://www.w3.org/2012/01/06-tagmem-minutes.html#action03

    <trackbot> Sorry, couldn't find user - Dan

    DKA: give me an action to include APIs, packaging, offline use,
    tools, monetisation

    noah: if you could just draft a section?

    DKA: ok

    JeniT: do Facebook apps have similar characteristics?

    DKA: the risk on mobile is apps running outside the browser, that
    could be done in the browser
    ... due to artificial constraints

    noah: widgets could run outside the browser, are they bad too?

    DKA: this is where it's a grey area, because some people don't think
    Widgets are the Web
    ... because they don't have addressability, for example

    noah: outside the browser, forward/back navigation doesn't work

    Ashok: are you thinking of Apps like iPad Apps?

    DKA: it's definitely not just on the mobile phone, but this whole
    class of device
    ... which uses the AppStore model
    ... which diminishes the importance of the web
    ... there are plenty of Apps that use web technologies
    ... but you can't use the web to download them, rate them, talk
    about them etc

    noah: I don't care about how I got the App but how you navigate out
    of the App

    yves: so what about the Chrome Apps?
    ... they are using web technologies

    noah: if they're not linking to things on the web, then that's not
    so good

    yves: the threat is the creation of a walled garden

    Ashok: +1

    DKA: so Chrome apps run in the browser, but you can only download
    them and use them in Chrome

    noah: should we start each section with 'Threat:'

    DKA: I think that's good: the threat is the browser is no longer the
    way that people find and download information

    noah: I'm want to focus on the risk/threat for Jeff

    DKA: the death of the browser as the mechanism for accessing
    information is the threat here

    Ashok: in the browser, you can go to a different web page, and from
    an App you can't

    noah: many Apps do it, but they break

    Ashok: this is a way to try to earn money
    ... to package something that you can then charge for

    yves: not only for paying, but for editorial control: you can censor
    things

    DKA: why should you care? because you won't be able to see
    information that isn't approved
    ... on the web I can find other points of view

    noah: most of this is stuff Jeff will be aware of
    ... perhaps we want to say that he should be more worried about
    losing this war

    DKA: there are other things about debunking claims such as not being
    able to charge for things
    ... or accessing location
    ... or accessing the camera

    noah: in my experience geolocation doesn't work as well in the
    browser as in an App

    DKA: the macro-issue is the other functions that the web can't do
    that Apps can

    noah: vendors that support Apps may limit the ability of the
    browsers to perform as well as the Apps do
    ... Apps have more complete access to the platform
    ... they lose flexible linking to other web pages
    ... the threat is that this remains attractive: the web hasn't blown
    these things away

    Ashok: if APIs on the phone are really that much better than the
    APIs from the browser, that's a cause for concern

    DKA: this is a complex area; highlighting some stuff on the
    technical level would be a good idea
    ... let me draft something for Jeff
    ... to give him some ammunition

    Noah: CAs

    Yves: we should note that there is work going on in IETF and other
    places to help...

    JAR: Jeff ought to be mobilising w3c to work on this issue. This is
    really important.

    Tim: do you mean the first response or designing a better system?

    JAR: I mean that it's not obvious where to go. We have some ideas...
    ... Issue is the trust structure...

    Larry: In some case, if we don't figure it out then things won't
    advance. But in this case if we don't figure it out then bad things
    will happen.

    Noah: I think we all agree.
    ... [wordsmithing the description]

    … I'd like to see a paragraph "the practical effect of this is that
    right now in certain countries users are being redirected to
    fraudulent or improper copies of web sites - and that there is no
    way to fix this in the immediate future."

    Yves: not only redirecting - but people having the feeling that they
    have a secure channel - and are not being spied on.

    Noah: We should start with some brief war stories - Another example:
    we have seen man-in-the-middle attacks to spy on politically
    sensitive traffic...

    Yves: as in Tunisia.

    Noah: I think it's important to say: right now it's not obvious how
    the technology will be deployed to stop this from happening.

    Larry: There's a concern that this is an architectural flaw rather
    than a set of isolated events. I share this concern.

    Yves: I can redraft this.
    ... we might expand on what we mean by trust issues...

    Noah: As long as the key points are up front.

    JeniT: can we move that up to the top of the list?

    Yves: I agree.

    … add "red flag here."

    Noah: Now - "SPDY and HTTP"
    ... The highlight here is - this is not a threat, this is something
    you should be aware of …

    Yves: there should be info at the bottom about the new efforts in
    this space - the IETF httpbis rechartering.

    Noah: I can redraft this based on what we heard from Mark
    Nottingham.
    ... now "Death of Protocols"
    ... Can someone offer an example of this?

    Yves: not many things are using web sockets in a way you could call
    a "protocol." You just wait for data to come in without having the
    framing of http...

    … I'm not aware of any widely deployed app using web sockets though.
    So it's a potential threat.

    JAR: What's written here sounds right.

    Noah: Can you give me an example?

    Yves: e.g. the way communication was done in the past before TCP…

    Noah: Why is that death of protocols rather than "death of
    standardised interoperable protocols."

    JAR: It's not the death of existing protocol. It's the death of the
    process by which people publish their protocols.

    Tim: It could be the birth of many protocols… Some of these may get
    standardised, some won't...

    JAR: The outcomes could be good. There were objections from within
    IETF - for where the locus of documentation is. The traditional IEFT
    way of doing things is to write a RFC, associated that with a port,
    etc… Locus of communication is in IEFT and with the community around
    that (e.g. those building firewalls, routers, etc…).

    … what people are bothered by is - even though innovation is
    supported - that it's disruptive.

    Tim: if you run over TCP then you can tai end-to-end without talking
    to people...

    Noah: We were in a world where code was hard to deploy - now when
    you go to a site and you want the weather, there's a chance the site
    will send you the javascript code at that moment to speak that
    protocol in order to get the weather. The code is mobile and hence
    the value of standard protocols is greatly diminished.

    Tim: issue Jonathan was raising - you used to take new protocols to
    the IETF. But as long as you use an existing underlying protocol
    then maybe you're safe now [for using these new protocols].

    JAR: I think this is complicated.

    … having to do with what layers in the stack have information about
    the traffic. It used to be that routers were pretty simple. Modern
    routers at wire speed are looking at things like the URI of an http
    request and making decisions as the packet goes by...

    … so it's a question of the locus of intelligent.

    Larry: 20 years ago some guy at CERN wrote some code and I
    downloaded it. The Web was deployed before there were any standards.

    Noah: But tim didn't download a new copy of the browser every time
    [he visited a web page.]

    Larry: IETF and w3c have policy initiatives around security,
    privacy, monitoring, ports, firewalls, etc… if there's never any
    need to do protocol review or standardisation, how do we retain
    those "community goods."

    <noah> Possible message to Jeff: "As dynamically downloaded
    JavaScript libraries are increasingly used to implement ad-hoc,
    problem-specific protocols to access data, the usage and value of
    Web technologies such as URIs and HTTP may be reduced."

    Tim: e.g. quality review.

    Yves: there's also the possible reuse of that protocol.

    <jar> goes to the network as a commons

    … if you're building something that gets widely used, and you're
    using a protocol that's not published then people will have a hard
    time reusing, etc...

    Tim: I think it's better to come to Jeff with possible failure
    scenarios.

    … one failure mode : when you buy some home automation hardware, it
    comes with its own Web server and runs its own protocol between the
    client and the server and as a result you have vendor lock-in.

    <noah> Possible message to Jeff: "As dynamically downloaded
    JavaScript libraries are increasingly used to implement ad-hoc,
    problem-specific protocols to access data, the usage and value of
    Web technologies such as URIs and HTTP may be reduced, and we run
    the risks that result from proprietary protocols. For example
    {insert Tim's example of home toaster controller here}."

    <JeniT> DKA: why is that any different now from in the past?

    <JeniT> Yves: the difference is it's done in the browser

    Tim: 2nd scenario : the toaster protocol might run on UDP so it
    brings my home network down…

    <Yves> it's not vendor lock-in, it's difficult upgrade path, no
    review on what can go wrong (security etc...)

    Tim: these are hidden protocols.
    ... What's breaking is the ability to construct things in a modular
    way.

    Noah: No this might be well structured but it's all very immediate.

    Tim: What am I missing?

    Noah: I'm saying the right model is - I'd like to use this on things
    that don't support javascript, I'd like to be able to implement it
    in multiple environments, etc...

    Tim: What you're trying to do is to combine multiple components...

    Noah: damage would be no freedom of choice in toasters.

    <noah> TBL: Issues include vendor lockin, badly designed (no IETF
    review)

    Peter: This happens now...

    JAR: difference is it goes through firewalls...

    Peter: I think the main difference is that it's going to happen
    within the web browser [with Websockets].

    Tim: example of using libraries - standardisation will happen
    between people making the libraries.

    Peter: my fear is that people will use proprietary protocols so that
    makes it more difficult for others to re-use data across the Web.

    Larry: people have already been layering for decades proprietary
    protocols over http. Maybe this is actually not a problem.

    Noah: I'd like to take a look at where we stand. We're mostly there
    except on this one.

    …worth another 10-15 minutes?

    JAR: What larry said.

    <Yves> +1

    JeniT: Yes I agree we shouldn't raise it to Jeff if we can't
    articulate a problem.

    +1

    Noah: anyone who could offer something to discuss on a telecon.
    ... Ok - for the moment this will not be included in the note to
    jeff unless someone comes forward with a proposal on the text.
    ... ok - Yves to draft something on "overlapping specs"; Dan to do
    apps and web apps; Noah to do Certs (to be moved to top with red
    flag); Yves to do SPDY; Protocols is out unless someone comes out
    with text to discuss; all - please send me paragraphs and I will
    integrate them.

    <scribe> ACTION: Dan to draft text on apps and webapps [recorded in
    [32]http://www.w3.org/2012/01/06-tagmem-minutes.html#action04]

      [32] http://www.w3.org/2012/01/06-tagmem-minutes.html#action04

    <trackbot> Sorry, couldn't find user - Dan

    <noah> ACTION: Noah to integrate input from DKA and Yves for note to
    Jeff, and draft section on CA Due: 2012-10-17 [recorded in
    [33]http://www.w3.org/2012/01/06-tagmem-minutes.html#action05]

      [33] http://www.w3.org/2012/01/06-tagmem-minutes.html#action05

    <trackbot> Created ACTION-660 - Integrate input from DKA and Yves
    for note to Jeff, and draft section on CA Due: 2012-10-17 [on Noah
    Mendelsohn - due 2012-01-13].

    <noah> ACTION-660 Due 2012-01-17

    <trackbot> ACTION-660 Integrate input from DKA and Yves for note to
    Jeff, and draft section on CA Due: 2012-10-17 due date now
    2012-01-17

    [end of discussion on Jeff note]

    <noah> [34]http://www.w3.org/2001/tag/group/track/actions/overdue

      [34] http://www.w3.org/2001/tag/group/track/actions/overdue

    ACTION-344?

    <trackbot> ACTION-344 -- Jonathan Rees to alert TAG chair when CORS
    and/or UMP goes to LC to trigger security review -- due 2012-01-01
    -- OPEN

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

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

    JAR: Answer has been "Ok - explain to users of the spec how to be
    careful."

Action Item Review

    <noah> ACTION-480?

    <trackbot> ACTION-480 -- Daniel Appelquist to draft overview
    document framing Web applications as opposed to traditional Web of
    documents -- due 2011-07-05 -- OPEN

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

      [36] http://www.w3.org/2001/tag/group/track/actions/480

    <noah> close ACTION-480

    <trackbot> ACTION-480 Draft overview document framing Web
    applications as opposed to traditional Web of documents closed

    ACTION-601?

    <trackbot> ACTION-601 -- Noah Mendelsohn to document in product
    pages wrapup of HTML5 last call work, leading to HTML next review --
    due 2011-12-27 -- OPEN

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

      [37] http://www.w3.org/2001/tag/group/track/actions/601

    <noah> action-601?

    <trackbot> ACTION-601 -- Noah Mendelsohn to document in product
    pages wrapup of HTML5 last call work, leading to HTML next review --
    due 2011-12-27 -- OPEN

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

      [38] http://www.w3.org/2001/tag/group/track/actions/601

    Noah: I believe I did this - can I close this action?

    <noah> close ACTION-601

    <trackbot> ACTION-601 Document in product pages wrapup of HTML5 last
    call work, leading to HTML next review closed

    <noah> ACTION-645?

    <trackbot> ACTION-645 -- Noah Mendelsohn to take off draft
    indication and put dates on URI Definition and Discovery Product
    page -- due 2011-12-29 -- OPEN

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

      [39] http://www.w3.org/2001/tag/group/track/actions/645

    <noah> close ACTION-645

    <trackbot> ACTION-645 Take off draft indication and put dates on URI
    Definition and Discovery Product page closed

CA Issue

    Noah: You could make a case this is a security problem that the TAG
    should be involved in in an ongoing way. Seems like a really
    important development to me. We should be involved.

    Ashok: It doesn't look like our's to tackle.

    JAR: Everyone should have awareness of, especially us.

    Noah: If we thought the Web was going to crumble then we should go
    to w3c membership and say that.

    JAR: at least 3 different solutions have been put forward and it's
    not clear [which is best].

    <jar> [40]https://www.youtube.com/watch?v=Z7Wl2FW2TcA I think

      [40] https://www.youtube.com/watch?v=Z7Wl2FW2TcA

    JAR: e.g. "SSL and the future of authenticity"
    ... …and a third one.

    JeniT: is there anything useful we can say to people developing web
    applications with SSL about what they should or should not be
    doing...

    <jar>
    [41]https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-
    against-google

      [41] 
https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-against-google

    Yves: i think it's more for users - that they should rely on more
    than just the ssl padlock...

    Noah: How urgent is this?

    Yves: If it's easy enough to divert DNS and create fake
    certificates...

    JAR: whole part of the video [above] is that it's very easy to do
    this.

    Yves: The first issue is that users should know that even if they
    think it's safe it might not be safe… E.g. in some countries even if
    they are using SSL then it might not be safe. In that case, they
    should be using secure VPNs…

    Dan: Isn't someone like EFF already providing that advice to end
    users?

    Yves: yes - EFF worked on https everywhere - working against fire
    sheep - but this can give the sense of false security. You need a
    bit of judgement.

    … do you want to access sensitive data on a network with https if
    you think you might be snooped on.

    JAR: The point of the 3 proposed improvements is that thinks don't
    have to be as bad as they are.

    … question of how do you bootstrap trust...

    … my intuition is tat it's important. Can we weigh in, review the
    solutions, etc…

    JeniT: Larry suggests we get someone to brief us on these solutions.

    JAR: What can w3c do?

    <masinter> Mark also pointed at
    [42]https://datatracker.ietf.org/wg/dane/charter/ effort in this
    area

      [42] https://datatracker.ietf.org/wg/dane/charter/

    Tim: One intriguing thing - they use the same keys for webid, ssl
    and ssh. If you use a key from one world in another world then you
    won't have to have on trust system for each domain (web sites,
    email, etc…).

    … with some interoperability you could use a mixture of different
    sources of trust.

    … if you join a group (e.g. an employer), you can get some
    certificates and a level of trust within that group.

    … e.g. Csail - they sign their own certs, and you have to make
    browser exceptions in order to use their [secure web sites].

    <jar> timbl: trust interoperability

    … there should be a better way to do that - when you join a group
    you get trust associated with that groups including email certs, web
    browsing certs, etc...

    Dan: I think getting experts in would be good.

    JAR: I think Harry Halpin could do that.

    Ashok: I'll ask Harry to join us on a telco and talk to us.

    [Next step: Ashok to ask Harry to join us and brief us on the
    security proposals...]

    JAR: I recommend watching the video.

    <jar> Looking at Harry's email
    [43]http://lists.w3.org/Archives/Public/www-tag/2011Dec/0083.html

      [43] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0083.html

    Noah: One think I'd note is that web app sec as a narrower charter
    than web security ...

    Yves: yes - mostly to work on cors.

    Noah: Security domain lead - should we talk to Thomas and ask him
    "read harry's note - tell me what you're already doing about this?"

    Dan: could we get Harry and Thomas on the next call to discuss?

    <scribe> ACTION: Ashok to ask harry and thomas to join us on a
    future TAG call. [recorded in
    [44]http://www.w3.org/2012/01/06-tagmem-minutes.html#action06]

      [44] http://www.w3.org/2012/01/06-tagmem-minutes.html#action06

    <trackbot> Created ACTION-661 - Ask harry and thomas to join us on a
    future TAG call. [on Ashok Malhotra - due 2012-01-13].

Summary of Action Items

    [NEW] ACTION: Ashok to ask harry and thomas to join us on a future
    TAG call. [recorded in
    [45]http://www.w3.org/2012/01/06-tagmem-minutes.html#action06]
    [NEW] ACTION: Dan to draft text on apps and webapps [recorded in
    [46]http://www.w3.org/2012/01/06-tagmem-minutes.html#action04]
    [NEW] ACTION: Dan to put together a bulleted list of items to go
    into this category [recorded in
    [47]http://www.w3.org/2012/01/06-tagmem-minutes.html#action03]
    [NEW] ACTION: Noah to integrate input from DKA and Yves for note to
    Jeff, and draft section on CA Due: 2012-10-17 [recorded in
    [48]http://www.w3.org/2012/01/06-tagmem-minutes.html#action05]
    [NEW] ACTION: Yves to prepare telcon discussion of protocol-related
    issues, e.g. Websockets/hybi (but not SPDY)Due: 2012-02-21 [recorded
    in [49]http://www.w3.org/2012/01/06-tagmem-minutes.html#action01]
    [NEW] ACTION: Yves to track IETF efforts on HTTP 2.0 & SPDY Due:
    2012-03-20 [recorded in
    [50]http://www.w3.org/2012/01/06-tagmem-minutes.html#action02]

      [45] http://www.w3.org/2012/01/06-tagmem-minutes.html#action06
      [46] http://www.w3.org/2012/01/06-tagmem-minutes.html#action04
      [47] http://www.w3.org/2012/01/06-tagmem-minutes.html#action03
      [48] http://www.w3.org/2012/01/06-tagmem-minutes.html#action05
      [49] http://www.w3.org/2012/01/06-tagmem-minutes.html#action01
      [50] http://www.w3.org/2012/01/06-tagmem-minutes.html#action02

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [51]scribe.perl version 1.136
     ([52]CVS log)
     $Date: 2012/01/13 17:54:01 $

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

Received on Saturday, 14 January 2012 04:06:21 UTC