W3C home > Mailing lists > Public > www-tag@w3.org > April 2012

Draft Minutes of TAG F2F 2-4 April 2012

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Fri, 20 Apr 2012 16:14:27 -0400
Message-ID: <4F91C3A3.8010107@arcanedomain.com>
To: "www-tag@w3.org" <www-tag@w3.org>
CC: Dominique Hazael-Massieux <dom@w3.org>, Chris Lilley <chris@w3.org>, Dan Appelquist <dan@bluevia.com>
Draft minutes of the TAG F2F of 2-4 April 2012 are now ready for review at 
[1] and in text-only form below. TAG members: please review these during 
the next few days, and correct as necessary, so we can take a formal vote 
to approve them on Thursday. Thank you.


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

============2 April 2012 =============

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

                                - DRAFT -

               Technical Architecture Group Teleconference

02 Apr 2012


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

    See also: [3]IRC log

       [3] http://www.w3.org/2012/04/02-tagmem-irc


           Ashok_Malhotra, Dan_Appelquist, Jeni_Tennison,
           Larry_Masinter, Noah_Mendelsohn, Robin_Berjon,
           Tim_Berners-Lee, Yves_Lafon, Henry_Thompson,


           Noah Mendelsohn



      * [4]Topics
          1. [5]Convene
          2. [6]httpRange14 - URI Documentation Discovery
          3. [7]part 1, use cases
          4. [8]Report on Paris IETF Meeting
          5. [9]Can publication of hyperlinks constitute copyright
          6. [10]Web Applications: Privacy by Design in APIs for
             Web Applications
      * [11]Summary of Action Items

    <trackbot> Date: 02 April 2012

    <noah> [12]http://www.w3.org/2001/tag/2012/04/02-agenda

      [12] http://www.w3.org/2001/tag/2012/04/02-agenda


    noah: agenda review
    ... couple of logistical announcements
    ... DanA will be joining us after lunch

    <scribe> scribe: Larry

    <scribe> scribenick: Larry

    noah: (reviewing agenda, visitor schedules)

httpRange14 - URI Documentation Discovery


      [13] http://www.w3.org/2001/tag/2012/04/02-agenda#httpRange14

    <scribe> chair: henry

    ht: I'll have a go at chairing, see how that goes
    ... plan: 45 minutes, trying to get a state of play review,
    want to hear what jar thinks we need to know. then spend 11-12
    slot seeing if we can identify a way forward
    ... my inclination is to not try to get to the resolution right

    jar: Jeni and I spent two hours yesterday talking about the
    plan for this session, and came up with an outline for a
    sequence of events
    ... roughly 5 parts (maybe 6)
    ... part 1: use cases, of which there are 2-3
    ... part 2: two architectures
    ... part 3: categorization of approaches
    ... part 4: visualizing the two roads to go down.... "what
    would it be like to go in that direction"
    ... part 5: criteria for making decision
    ... part 6: actually making a decision

part 1, use cases

    jar: RDF spec from 1997, section 5, Examples
    ... http:/www.w3.org/TR/WD-rdf-syntax-971002/
    ... "RDF is a foundation for processing metadadta"
    ... this is the first of 2.5 use cases. What's going on here is
    you're making a database about bibliographic information, using
    sparkle or some other results
    ... RDF was motivated by PICS whichc was about rating, before

    ht: (want a sense of how jonathan is using the terminology)

    jar: this is the way i see this use case, as formulated, which
    i translated into a form that makes sense now
    ... "If I do a get, I will get something which has the
    ... second use case:


      [14] http://www.w3.org/TR/WD-rdf-syntax-971002/

    <noah> I'm very surprised the assertion in the example is
    claimed to be about the representation. I had assumed the
    assertions were about the resource. e.g. If the assertion is
    "created-on-date", then I assume that's the resource, not the
    representation that was created. If I really need to talk about
    representations, then I should find a way to get URI for the
    (various) representation(s)

    jar points to

    <?namespace href="[15]http://docs.r.us.com/bibliography-info"

      [15] http://docs.r.us.com/bibliography-info

    <?namespace href="[16]http://www.w3.org/schemas/rdf-schema"

      [16] http://www.w3.org/schemas/rdf-schema


    <RDF:assertions href="[17]http://www.bar.com/some.doc">

      [17] http://www.bar.com/some.doc

    <bib:author href="#John_Smith"/>



    <RDF:resource id="John_Smith">

    <bib:name>John Smith</bib:name>


    <bib:phone>+1 (555) 123-4567</bib:phone>


    jar: the RDF:resource id="John_Smith" in the second use, is
    really about the person
    ... "URI-based structured data"
    ... expand on this: netflix use case, we have actors, films,
    separate files in some format, in each entity, there might be
    some application
    ... 3rd case is one i will talk about an demand, the use of a
    URL from Amazon to talk about a book

    ht: press on ...

    jar: I've been trying not to make this RDF specific
    ... About "two architectures": where we are now, for whatever
    we are, people are wanting to use hashless URIs for both use
    ... the relationship between the retrieval results
    ... that's my analysis ...? "the other one is description. The
    content you get back is different ..."
    ... I'm saying a fact about the two ways these fragments are
    meant to be used
    ... in the one case, the URIs are being used as forming a
    document web. In the other case, the content you get back is
    more of a "REST"...
    ... Tim's vision and Roy's vision are different

    ht: please be more specific

    jar: Roy's latest formulation is "the representation is a
    record of the state of the resource"

    noah: if a "hashless http refers to me" ?

    jar: in Tim's version, people don't have hashless URIs?

    <ht> "Relationship between the representation and the resource
    is arbitrary and application-dependent" Roy Fielding, as
    channelled by Jonathan Rees

    jar: "If we need to"
    ... i think it might be useful to go over the three definitions
    of the word 'representation'

    <ht> "The way I interpret Roy, a server could validly return a
    JPG image of [Noah] with a 200 in return for a GET of a URI
    alleged to identify Noah"

    <ht> [Above quote from JAR, I think]

    larry: *munch* (eating another spoon)
    ... I think "alleged" is a problem

    jar: I've found 15-20 definitions of 'representation', 3 of
    which are interesting
    ... Rep #1: TBL, 2616? email, the word representation, comes
    from content negotiation,

    "Encoding-format-desensitized methods and means for
    interchanging electronic document appearances." Patent no.,
    5,210,824, 1993 May 11 (filed Mar., 1989).

    (JAR reviews matrix on board)

    jar: Rep #2: REST, by Roy fielding, in thesis, 3 publications,
    and in HTTPbis
    ... the type of indentified resource is unconstrained
    ... this is similar to ordinary language use of the word
    'representation', "is a picture of noah a representation of
    noah, yes". Is a picture of jonathan a representation of
    ... "Definition of Reputation #3" by 'fiat' -- if the URI
    identifies something and you do a GET and you get some bits,
    then by definition, the represenation of the resource
    ... Yves is correct that Roy is working to correct the
    terminology to be consistent with Rep #2

    <JeniT> Definition in HTTPbis:


    <JeniT> "A resource representation is information that reflects
    the state of that resource, as observed at some point in the
    past (e.g., in a response to GET) or to be desired at some
    point in the future (e.g., in a PUT request)."

    jar: does "Information Resource" belong here. I don't
    understand, in roy's view, ways that we should not use the term
    "Information Resource" in this discussion

    <Zakim> noah, you wanted to ask about assertions about
    resources vs. assertions about representations

    noah: let's say the triple says "was created on"
    ... and it's my thesis, does the assertion apply to the
    representation or the resource

    jar: my theory of resources in sense 1
    ... if you say "if you do a get, you'll come up with something
    that satisfies the metadata"
    ... it is my belief that there is an operational behavior
    ... the operational behavior is predictive

    <Zakim> Larry, you wanted to note that I think representation
    vs. resource is irrlevant

    <noah> ScribeNick: noah

    Larry: I am interested in a view where the distinction between
    representation is not interesting, therefore the definitions of
    the terms are unimportant. We don't need the words.

    jar: Right, we just need to talk about the relationship between
    the two.

    Larry: No, we don't want to use the words at all, therefore
    there's no issue of the relationship.
    ... I think it's possible to not talk about resources,
    representations, HTTP status codes, or what happens when you do
    a GET. I like that story.

    jar: Everything I'm talking about is empirical. I'm talking
    about these two framings, and related them to the use cases.

    Larry: I don't think the use cases are different.

    jar: Consider the Flickr use case: you have two things... a
    description, and what it describes...and they have different
    properties. Thus, you NEED to say which one you're talking

    Larry: No you don't.

    timbl: Why not.

    Larry: We're having a conversation. In the old days, using
    English or French. You had languages you both understood, with
    dictionaries like OED to refer to.
    ... We communicate because we use the same language, not the
    same dictionary.
    ... Then we invented the Web, on which we can not only exchange
    text, we can annotate text, and hyperlink it. We can now say
    this Moby Dick was written by Melville, and can hyperlink, and
    can give representaitons e.g. in different natural languages.

    <ht> "This book I read, it's called 'Moby Dick', it was written
    by Hermann Melville, it has a green cover" LM

    Larry: Then we can reference things like Wikipedia we kind of
    understand how to share and retrieve.
    ... But then we wanted more...to make it more formal with
    triples... e.g. to formally say things about a book, using URIs
    to make formal the objects being discussed, who wrote it, etc.
    ... That is more precise, yet ambiguity remains. Maybe you
    can't tell if I'm talking about the book or the Web page about
    the book.
    ... Maybe the triples weren't good enough, in not allowing us
    to distinguish things we care about.

    jar: In 1998, it was very clear in the RDF draft (some mumbling
    in the room as to whether everyone agrees)

    Larry: We invented RDF, rev'd it, and still have ambiguities,
    some of which make us uncomfortable. That's just the way it is.
    We can't, in my view, retrofit now. We have to live with the
    ambiguities. Specifically, we can't do it by now more precisely
    stating what a URI means.

    ht: Jumping in...Jonathan has said repeatedly that 1998 draft
    was clear, but I don't think it addresses Larry's concern. I
    think the example in the spec is clear.

    <Larry> we can't retrofit the definition of what a URI means in
    order to fix this possible ambiguity in RDF.

    ht: It's unclear whether the example in the 1998 draft is about
    Moby Dick or the Web page about MD

    Larry: Even if you think RDF has got metadata...the library of
    congress has Abraham Lincoln's glasses, the glasses themselves,
    in the catalog.

    jar: The description is in the catalog.

    Larry: Right, but the catalog entry is for the actual glasses.

    <Larry> ScribeNick: Larry

    jar: the RDF draft itself does not resolve this question, in
    that sense that Larry is right. It is my belief that certain
    people had this view #1 in mind, that if you do a GET you will
    get something that has the property
    ... one example is "automatic mashups", you do a query of
    documents... and you produce something that has one paragraph
    from each document
    ... second example: text mining, what do you point your
    database on?

    ht: i think you're right, they wanted (Guha and Tim Bray) to
    give web docs metadata

    <Zakim> timbl, you wanted to say that JAR's way of defining
    'content of' is very good and to

    timbl: You (LM) said RDF had an ambiguity; there is no
    ambiguity, the triples aren't ambiguous
    ... RDF constrained the ways in which ....

    <JeniT> ScribeNick: JeniT

    timbl: RDF was completely clear: under my view, it's clear what
    the URIs refer to
    ... which is documents
    ... This constrained how you could use URIs, but it is not

    <timbl> The RDF system had no inhereent ambiguity om the trips.
    It did decide to use URIs and HTTP, and in designing them into
    the system, it constrained them, so URIs adn HTTP were
    interpreted in a more cconstrined manner which produced a very
    nice very clean system, whcih was very useful. But it involved
    imiteing the way one talks about URIs and HTTP

    <timbl> compared to what was in REST.

    jar: there are applications where you need to know whether the
    bits are content rather than description
    ... for example, showing the first paragraph of all the
    documents that can be found
    ... and it needs to make sure that the paragraphs are content
    from the documents, not from descriptions of the documents

    ht: if I want the train schedule, to display the numbers, you
    have to pay attention to the response code...
    ... if it comes back as 404 then you know you don't want to
    display those numbers
    ... you need to know whether the bits are the document or about
    the document

    jar: you need to know whether the bits are the content

    timbl: the concept of a document is crucial
    ... it's like the content of a string

    <ht> jar: It's like 'quote' in LISP

    larry: this is a distinction that I think is impossible to make

    timbl: the URI of the content of Moby Dick and the URI of a
    review of Moby Dick are different

    larry: can we describe this in terms of communication,
    asserting things in English, then in markup, then in triples

    noah: maybe we are tripping over what may be distinguished and
    what's worth distinguishing
    ... a document rendered with different backgrounds on different
    ... these are two artefacts, roughly different representations

    larry: I'm not happy with "I have a document and I give it a

    noah: I minted a URI by leasing a domain name etc etc

    larry: I'm not happy about 'minting' and 'owner'

    noah: two operations were done, two sets of bits came back
    ... there were two artefacts, and we can't say they're the same
    ... one had a blue background, one not
    ... whether we care about that is something else
    ... perhaps you're saying we don't care about that

    larry: RDF doesn't let me express things that I want to express

    timbl: I think originally said that the difference between
    description and content was not one we could make

    <Larry> not one we could make reliably

    ht: clarification of relationship between resource and
    representation under Roy's view

    jar: it cannot be predicted what the relationship is
    ... there are applications where the content/description
    relationship is essential for the application to work
    ... you need to be able to identify whether something is
    content or description

    larry: there may be applications that you want to build, that
    depend on that distinction, but I do not think you can make
    that distinction reliably

    ht: there are people who are building these applications,
    because they assume a uniform answer to the question
    ... if they own both ends, they can satisfy the uniform

    <Larry> so the applications are unreliable. maybe they're
    reliable enough for the applications to be useful anyway

    ht: own the server and the client
    ... so there's no possibility of disagreement

    <Larry> the web is unreliable -- we get 404 not found all the
    time, but the web is sitll useful

    timbl: the RDF folks have built systems where they own both
    ends, but they include things outside that space, and that's
    the problem

    <Larry> i think this really leads into persistence, that we
    want <A> <R> <B> to be mean the same thing for all time, but
    it's unreliable

    jar: we should be able to ground this in a discussion where
    there's an application that do want to be able to make that

    larry: we have a system where all URIs are not cool, in 10,000
    years they will stop working

    jar: we can scope to something within the next 5 minutes
    ... so you're right, but we're willing to make bets

    larry: there are applications that want to make distinctions
    reliably, and can't, but that doesn't mean they can't be useful
    ... the web is not completely reliable, but it's still useful
    ... getting the first paragraph of the review of Moby Dick is
    still useful

    ht: let's move on to 'proposal's

    <Larry> ScribeNick: Larry

    ht: let's spend 15 minutes on the third item of the agenda

    jar: supposing that we want to make distinctions, let's look at
    the proposals
    ... what are the possible sources
    ... in this case, let's suppose you can determine one bit of
    information, "content" vs. "description", where can this come
    ... (1) it could be in the specification

    ht: that's the state we could have been in, if Dan & Tim could
    have enforced the hash convention

    jar: (2) it could be in the status code, headers, content ...
    it could be in the response
    ... or the information could come from the exchange in http
    ... (3) 3rd source: "the message", the use of the URI, the
    document in which the URI occurs
    ... (we're not talking about the merits of these)
    ... information could come from any of these places, or a
    combination of them

    ht: this story is situated in a context where you sent me a
    message that contains a URI

    noah: there are other contexts?

    ht: we're trying to reduce the uncertanty of a message

    noah: "There are situations where i might just find a URI" ?
    ... there might "I just saw a URI?"

    jar: categorization of approaches (1), (2) and (3), the
    architecture i attributed to tim that is very heavy on (1) that
    does also involve (3) in the language spec ....
    ... ... in the GET + 200 case of (2), 'retrieval', the way that
    i make this distinction, i'll look at "httpRange-14a" and then
    I've answered the question
    ... we could have another answer, "httpRange-14b"
    ... Roy believes HTTPbis can't answer this question
    ... "He cares not to discuss this"
    ... New taxonomy of change proposals
    ... "Fixed mode" proposals: 'the answer comes from source (1)"
    ... proposal httpRange-14Strengthened
    ... AlwaysDescription
    ... these are the two fixed answer ones
    ... "Variable Answer" proposal:

    <JeniT> ScribeNick: JeniT

    jar: 1. 'no agreement' / 'nuclear' option -- no statement about
    relationship between resource and representation
    ... 2. Mode determined from server response
    ... 2a. new header that always answer the question, which has
    to always be present in order to tell
    ... 2b. Mode sometimes implicit
    ... 2bi. by default content, header means that it's not content
    but description (TimBL proposal for Document: header)
    ... 2bii. by default not content, header/message says it's
    ... 2c. Mode determined at point of use
    ... you can't tell from the HTTP exchange at all
    ... only from the use of the URI

    ht: these could fall into two categories in the same way as 2b,
    different defaults

    jar: 2d. Mode determined from the request (eg MGET, Want-Other)

    timbl: I don't see how 2c works
    ... how does the server know what to give back?

    jar: the application will interpret whatever response the
    server provides back in the way indicated by the context in
    which it got the URI

    ht: handing chair back to noah

    noah: we have some unscheduled time

    <ht> [My 'want-other' proposal about a request header is here:

      [19] http://www.ltg.ed.ac.uk/~ht/wantOther.html

    ht: I would like 1-1.5 hours

    <scribe> ScribeNick: Larry

    Larry: would like to minimize the amount of time on this

    <ht> The want-other document has a potentially useful input to
    the role-playing discussion

    timbl: this has taken up a huge amount of mailing list... would
    like to make progress in f2f

    JeniT: I think we can make some progress at this F2F

    ht: I think the "role-playing", the next step wants to be "What
    life would be like in the major categories" ?

    henry put a pointer that has an analysis by cases

    <ht> I.e. an analysis by cases of what happens wrt server vs.
    client uptake

    noah: we'll spend a significant amount of time on this... jeni
    made the case... we pay a lot to swap in and out

    <JeniT> ScribeNick: JeniT

    <Larry> my criteria: (1) persistence... meaning should persist
    independent of what happens in DNS

    <Larry> (2) URI equivalence ... how to decide on whether URIs
    are the same

    <Larry> (3) reading on registries, registered values, vs. using
    URIs in protocols

    <Larry> (4) play without using 'owner', 'mint',...

    <Larry> (5) read on MIME, ...

    <Larry> (6) doesn't rely on 'resource/representation',
    'defining what a resource is or whether two resources are the

    larry: A story without talking about owners
    ... it should work for all URIs, not just HTTP
    ... without a distinction between information resource or
    non-information resource
    ... RDF has to be taken as a context, and there are other
    languages that might have different answers
    ... like to talk about persistence, which is part of not
    talking about HTTP
    ... something where there's no timeout
    ... something that someone can put in a book

    jar: a story in which timeout is not implicit

    timbl: I suggest that's out of scope

    larry: I'm saying what's important to me
    ... it's important that it works in archives
    ... I'd like it to talk about equivalence of URIs, but not
    equivalence of resource
    ... we don't have a language for naming resources aside from
    ... we can compare code points in URIs
    ... but not resources
    ... We had some other related findings around URIs and

    jar: what's the criterion that comes from registeries?

    larry: the discussion about URIs is more appropriate around
    ... where there is an owner
    ... URNs have a story where there are naming things, and
    documentation and owners
    ... but that's the only naming scheme that has that property
    ... no one gets to say what HTTP URIs mean other than the
    implicit meaning

    jar: so the criterion is that it should touch on the
    relationship to registeries?

    larry: touch on the relationship between these things
    ... I laid out a story around talking in English, then markup
    languages, then triples

    <noah> Whiteboard photos for inclusion in agenda:


      [20] http://www.w3.org/2001/tag/2012/04/httpRange14Board2_1000px.jpg

    larry: whatever proposal we accept should be cast into why we
    care about this as a way of enhancing communication

    <noah> Closeup of small print on upper right:

      [21] http://www.w3.org/2001/tag/2012/04/httpRange14Board2Closeup.jpg

    larry: with the communication being enhanced, so that it's not
    just talking about philosophy
    ... I'm looking for a use case where adopting a solution helps
    ... persistence is the one that's hardest, because no one is
    talking about it and I think it's important

    noah: I have a couple of evaluation criteria too
    ... there are constraints and good practices in Architecture of
    the WWW and in our findings
    ... eg don't use one URI to identify two different things
    ... that interactions in HTTP should be self-describing
    ... if we have a solution that involves HTTP interactions, we
    should make sure they are consistent

    <Larry> "should work for all URIs, not just HTTP ones, should
    work for mailto:, data:, ftp:, file:, ..."

    jar: the criteria for the story is different from criteria for
    the solution

    noah: apply the criteria at the appropriate point

    ashok: I'm nervous about adding lots of equations
    ... work on some criteria and then worry about the others

    ht: I want a solution that we think is going to change
    ... there are two outcomes that are plausible
    ... one is that we figure out that the current state of play is
    ... the other is that we adopt a new position
    ... if we're going to do that, we had better have a vision
    about how we get behaviour to change to go there
    ... we can't just say what the Right Answer is and then say
    we're done

    timbl: my criteria is that the specific cases that got us into
    this discussion should be addressed
    ... eg 303s, OGP, Flickr should be addressed specifically
    ... add Dublin Core as a use case
    ... and an answer where we're confident that if they need to
    change, we can get them to change
    ... it must work for Dublin Core and FOAF and RDFS
    ... ie hash-oriented vocabularies must continue to work

    noah: at what point is it worth identifying one or two
    solutions might be promising, based on intuition
    ... we can ask about whether those hold up
    ... then at the end we can look at the other proposals

Report on Paris IETF Meeting


      [22] http://www.w3.org/2001/tag/2012/04/02-agenda#IETFParis

    Yves: about HTTP/2.0


      [23] http://www.mnot.net/blog/2012/03/31/whats_next_for_http

    Yves: we had representations about 1. SPDY


      [24] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-4.pdf

    Yves: 2. from Willy Tarreau, whose view came from an
    intermediary point of view, so included info from Squid
    ... 3. Waka from Roy Fielding
    ... 4. Microsoft S+M
    ... the goal now is to get more concrete proposals on the
    mailing list for evaluation before the next IETF meeting in
    July in Vancouver

    <Larry> pointers are in mnot's blog

    Yves: either one document to use as a basis, or two to be
    compared, one which will fail
    ... most of the proposals are for multiplexing at the
    application level

    noah: SPDY is like that?

    yves: yes
    ... layer 7
    ... the main discussion about SPDY is about the use of TLS or
    ... on the mailing list, though that wasn't so evident in the

    <noah> noah: right, so not e.g. the Google Maps application,
    but rather the Application layer of the network stack

    yves: there was one comment about authentication methods
    ... the goal would be to completely cover HTTP/1.1 but be able
    to do extra things

    jar: is there an example of something you would be able to do
    in the new protocol?

    yves: eg a new method of authentication

    larry: eg Waka includes examples of a single request naming
    several targets (MGET)
    ... that would be a new feature or an optimisation
    ... what I was interested in is that SPDY is slower for some
    ... it requires some optimisation/prioritisation in the client
    to be used effectively
    ... eg high priority for the first part of the document, low
    for the rest, so you get image headers quickly
    ... it's about performance/reliability/security
    ... and latency
    ... so the features are oriented around that
    ... earlier, I sent out a list of IETF meetings of interest, so
    I can go through that list

    <Larry> APPSAWG - "Applications Area Working Group WG", and
    APPAREA (Applications area) Most things of interest to W3C are
    in the "applications" area The meeting reviews topics of
    interest, new BOFs, as well as ongoing documents

      [25] http://tools.ietf.org/wg/appsawg/

    larry: I talked with Thomas and Mark about IETF/W3C
    dependencies and how to reduce them
    ... normative references in W3C specs to IETF specs in progress
    ... Apps Area WG meeting
    ... Ned Freed's document on updating MIME registration
    ... new draft just out, soon to be last call
    ... if we want anything to change about MIME type registration,
    we need to get it into this document

    yves: we already said something about fragments

    larry: yes, but we should make sure that it's saying what we
    want it to say

    noah: what are the timing limits?

    larry: I don't know, but soon

    yves: I looked at a recent version, and it looked ok

    noah: it seems like this is something the TAG should look at
    ... does anyone else want to sign up to double check?

    ht: I will try to find the time, to see if the mime type to URI
    conversion is universal and reliable
    ... it's IANA that manage the registry
    ... you can get something back for some of them but not all of

    larry: I suggest we schedule a phone conference to review this

    noah: I need the URI to the document

    <Larry> [26]http://tools.ietf.org/wg/appsawg/

      [26] http://tools.ietf.org/wg/appsawg/


      [27] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04

    larry: the media type reg document is the one we need to review
    ... there is another one we need to talk about which is
    deprecating X-

    timbl: is it good?

    ht: yes
    ... it does say that using prefixes generally is a mistake, for
    reasons noah will love

    <noah> ACTION: Noah to schedule (soon) TAG telcon review of
    gs-04 - Due 2012-04-17 [recorded in

      [28] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04

    <trackbot> Created ACTION-680 - schedule (soon) TAG telcon
    review of
    gs-04 [on Noah Mendelsohn - due 2012-04-17].

      [30] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04

    larry: it's an interesting document that's worth reading


      [31] http://tools.ietf.org/wg/appsawg/draft-ietf-appsawg-xdash/

    larry: I like this document, but I think TAG members should
    read it

    <ht> ACTION: Henry S to prepare TAG discussion of
    gs-04 - Due 2012-04-17 [recorded in

      [32] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04

    <trackbot> Created ACTION-681 - S to prepare TAG discussion of
    gs-04 [on Henry Thompson - due 2012-04-17].

      [34] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04

    noah: should these be reviewed together?

    <timbl> "Deprecating the X- Prefix and Similar Constructs in
    Application Protocols"

    larry: they are independent, and the X- document may not
    require TAG discussion, though I recommend reading it

    <timbl> and Similar Constructs

    Larry: Not convinced we need telcon discussion of x-prefix, but
    TAG should review.

    noah: OK, I'll only schedule x-dash if asked.

    robin: should this be brought to general attention within W3C?
    ... should it be sent to the Chairs list for broader review?

    larry: yes, that would be good
    ... there's another document which was discussed


      [35] http://tools.ietf.org/html/draft-nottingham-appsawg-happiana-00

    <noah> Who's going to send it to chairs' list? I suggest Larry
    as he has most context, but could do it if that helps for some

    larry: being prepared to be accepted by the Apps Area WG
    ... talking about the process around getting things into
    ... based on the happiana effort
    ... that document is even more important for Chairs at W3C
    ... that's it for the AppAreaWG meeting
    ... on to WebSecWG
    ... mainly working on strict transport security & TLS
    ... also an issue around the mime sniffing document, which has
    ... the security problem could be addressed by giving sniff
    content a different origin
    ... if you have overridden the mime type, then you have given
    it a different origin
    ... this would address the cross-origin problems that arise
    from sniffing
    ... and I have not seen counter examples
    ... it was discussed and dismissed because "browsers won't do
    ... but browsers don't do what's being said anyway
    ... why not have a different fantasy
    ... email clients do sniffing all the time
    ... the Web Security Handbook talks about sniffing
    ... just like we have URIs in different contexts, does sniffing
    happen differently in different contexts
    ... meant to go to URNbis
    ... WG revising URN document
    ... the TAG has expressed opinions about URNs, and I wish I had
    ... we should review their documents

    jar: I think Julian has been paying attention to what they're

    larry: my opinion has changed about them
    ... it may have been a design goal to have something persistent
    ... in fact it is not about persistent, but about ownership
    ... there's no owner of an HTTP URI, but there is one about
    ... Technical Plenary on browser security
    ... HTTP 1.1 is reaching closure

    yves: there's currently discussion about folding back documents
    together, adding a Part 0 so it's easier to find stuff
    ... merging Parts 1-3
    ... not sure about Part 0
    ... currently Part 4-7 are in IETF last call
    ... everything else should be in last call from the last draft

    larry: these are core documents, and the TAG should review them

    yves: most particularly Parts 1-3, the others are extensions

    jar: Part 2 is pretty important

    yves: wait for next draft for review

    noah: we often say we should review things, but we don't get
    people's attention to review them
    ... perhaps an email that points to particular things

    jar: I could point to the parts I've been paying attention to

    <noah> ACTION: Jonathan to suggest to TAG sections of HTTPbis
    specification that TAG should review - Due 2012-04-17 [recorded
    in [36]http://www.w3.org/2001/tag/2012/04/02-minutes#action03]

    <trackbot> Created ACTION-682 - suggest to TAG sections of
    HTTPbis specification that TAG should review [on Jonathan Rees
    - due 2012-04-17].

    yves: Dom should be able to report on RTC web

    <jrees_> Note to minutes editor: Please add link
    3.html at end of previous topic (that's the emacs buffer that
    was projected)

      [37] http://lists.w3.org/Archives/Public/www-archive/2012Apr/0003.html

    yves: it was also about security

    larry: security is what makes most protocol design hard
    ... because you can't just optimise for performance and
    ... you have to design against hostile players

    ht: what's HyBi doing?

    yves: it's WebSockets
    ... not the API, the protocol

    larry: the relationship between IETF and W3C work in many of
    these areas is that W3C focuses on API in JS on how you invoke
    it, and IETF on what goes on the wire

    noah: I had missed these were the two sides of the same coin

    larry: I don't know what the status is
    ... the TAG should have a review or invite someone to come and
    talk to us about it
    ... where we don't have the impetus to review it ourselves, we
    should get someone in

    ht: this is close to home because it's getting integrated into
    ... we have to be sure this isn't going to change the
    architecture of browsing over the next 5 years

    larry: I think we should look for someone to come and present
    to us

    noah: any suggestions about who?

    yves: Thomas is watching this

    larry: we might ask Thomas to recommend someone
    ... there was a BOF, where I gave a presentation, to consider
    the document format of RFCs

    <noah> ACTION: Yves to figure out who might be a good choice to
    present Hybi (and as appropriate WebSocket protocols) to the
    TAG [recorded in

    <trackbot> Created ACTION-683 - Figure out who might be a good
    choice to present Hybi (and as appropriate WebSocket protocols)
    to the TAG [on Yves Lafon - due 2012-04-09].

    larry: the driving use case is documents that need non-ASCII
    ... to show encoding
    ... IETF does allow alternative presentations in PostScript and
    ... Martin Durst submitted a document on internationalisation
    of mailto URIs
    ... where the PDF version has examples that are in Unicode
    ... running a pre-processor on the XML so that you can have an
    HTML version with Unicode, and a text version in ASCII
    ... the IRI WG
    ... again, planning on last calling IRI documents before next
    IETF meeting

    ht: please could you tell me when the XML Core WG should look
    at those

    larry: there are four documents:
    ... guidelines & process for registering schemes
    ... takes 3987 which used to be one document, and split out
    section on comparison and bi-directional IRIs
    ... the comparison document needs work, because it's a security
    document to avoid spoofing
    ... it can't be a ladder
    ... my take is IRI everywhere is not the right answer
    ... that there are some contexts where you will want URIs

    Adjourn for lunch

    <robin> ScribeNick: robin

Can publication of hyperlinks constitute copyright infringment?



    noah: worth reviewing the goals of this work



    [NM reads from the product page]

    jar: who wrote that, it's really good?

    noah: we did it together
    ... we can always change these goals, but we should do so


      [41] http://www.w3.org/2001/tag/products/PublishingLinking.html

    noah: we claimed PR in 2012-06, that seems tight

    <JeniT> dated version:


    noah: DKA, are you avaialble for more work on this?

    DKA: not in an official capacity, but I will help

    ashok: how do we make sure it is valuable to policymakers

    noah: I don't know, trying to get us in a mindset where we try
    to make it useful to them
    ... we can try, and if it fails learn from our errors

    ashok: how about asking them earlier if it helps

    noah: not sure we want to debate this now

    Larry: I think it would be useful after reviewing the draft to
    look into administrative next steps
    ... e.g. forming a CG around this



    noah: review the draft
    ... aiming for FPWD

    JeniT: my aim for this session is to get agreement on
    ... what I'd really like to do is focus on points that people
    feel strongly should prevent it from FPWD
    ... rather than editorials

    <Zakim> timbl, you wanted to say that JAR's way of defining
    'content of' is very good and to

    JeniT: editorials should be sent by email
    ... is there anything that people want to say fisrt off?

    Larry: this is a marvellous piece of hard work, my only
    concerns are about positioning and how we move forward with

    ashok: me too

    Larry: no matter how much we polish it, we will get feedback
    and divergent comments

    JeniT: but the only way to get those is to put this out there

    Larry: yes, but I would like to encourage their participation
    ... (in SotD)

    [JT goes through section by section]

    JeniT: Abstract

    timbl: this isn't an abstract at all

    jar: matching with goals, does more than set definitions for
    ... try to match the abstract with the goals from the product
    page which were really good

    Larry: the product page could be the abstract

    noah: extract some of it at least

    Larry: not an academic abstract, treat it like an ad for why
    people should read it

    ashok: it mentions issues that were raised to the TAG - were
    they really raised to the TAG?

    Larry: I'd get rid of the bit about legal issues

    JeniT: OK
    ... we'll rephrase that last paragraph

    DKA: pull it out, highlight that in introduction

    noah: can be very picky, but don't want to drag the group down
    ... but since we're writing for a community of lawyers we
    should be ruthless about drawing clear distinctions
    ... do people agree that that level of care is required?

    <Larry> I think we should indicate that we need to be ruthless,
    but not before we publish FPWD

    noah: concerned that this could be used in court

    jar: there's a tension between explaining words used in our
    community versus words defined by this document

    <Larry> explain words used in the community, as well as
    defining specific terms which could be used more precisely

    jar: if the goal is former, then entries need citations (though
    probably good as a FPWD)
    ... different goals: being clear, and explaining usage

    noah: users versus user agent, not clear

    <Larry> I think we have to do both

    jar: careful definition of UA in document, different from usage
    in some places

    JeniT: different places that define these things are

    jar: agree, but hard to resolve to tension

    Larry: the document may have to do both
    ... explain how terms are used in the community, and where
    there are contradictions come up with a new definition and
    recommend caution in future

    <Zakim> Larry, you wanted to argue for doing both

    noah: usually in the community UA == browser
    ... but here the definition is different because it's anything
    that accesses web content

    JeniT: what I'm taking away is to go through that set of terms,
    find citations/existing uses, and discuss the multiple
    existing/confliction terms then make sure the document is

    noah: be precise where we can be, and if it's inappropriate
    signal it
    ... UA is an example of this

    timbl: for the TAG in general, the idea of UA is really
    ... for me, a UA is a piece of software that represents me
    ... when you put User-Agent, you're representing someone else

    <Larry> unfortunately, "User Agent" is also used for
    identification of the HTTP client, even when it isn't working
    on behalf of any particular user.... a spider or web crawler
    has a "User-Agent" string. It was an error to name this "User
    Agent" in HTTP

    Larry: the problem is that User-Agent header is used to
    identify the web client rather than a UA

    noah: explain the different uses in technical community, and
    say which one is used here

    Larry: in most cases there isn't a problem, but for legal cases
    it may matter

    JeniT: arguably spiders are acting on behalf of someone

    Larry: but there's no identifiable user

    <timbl> Many subsystems with thin the web, like proxies and
    archives, are automated and incapable of exercising moral
    judgement, and requiring them to would be impossibly onerous.

    JeniT: moving on to Introduction

    <timbl> ^ attemtp to capture the best practuces in a scentence
    for the abstract

    <Larry> well, or at least for identification of whether there
    is a single responsible person for whose benefit the agent is

    timbl: Abstract is very good compared to most abstracts out

    <noah> 1.0 Introduction:

    <noah> I suggest chg/The page itself may cause/logic encoded
    with the page may cause/

    noah: reason is, we in the community understand what it means
    when we say "the page cause a retrieval", but that notion would
    seem bizarre to people outside
    ... hence the use of "logic", which is easier to explain

    jar: the notion of agency is central, because this is legal -
    who causes something to happen?

    <noah> Well, it's really that, in the real world, pages don

    ashok: yes

    <noah> don't caus things to happen.

    ashok: have you looked at the legal interpretation of agency,
    there's a whole bunch of stuff there

    <noah> 2nd paragraph.

    jar: not sure it's relevant here, might be useful in writing
    the document, but not necessary to capture it directly
    ... good thing to put on the TODO list, but no need to prevent

    ashok: yeah

    <noah> Suggest chg/Proxy servers and services that combine and
    repackage data from other sources may also retain copies of
    this material, due to the user's original request for the
    page./Proxy servers and services that combine and repackage
    data from other sources may also retain copies of this
    material/ (I.e. delete phrase at end)

    <noah> Reason: proxy servers wind up holding onto things for
    lots of reasons.

    timbl: agency makes my rant stronger about UAs acting on behalf
    of users

    <noah> 3rd para:

    <noah> Still other services on the web, such as search engines
    and archives, make copies of content as a matter of course

    jar: "intents and conditions...." don't use passive -- this is
    not editorial because agency matter

    <noah> Suggest after "matter of course": in part to facilitate
    the indexing necessary to their operation, and in part to
    enable presentation of search results"

    <noah> Suggest delete: (as it enables the content to be found
    more easily)

    DKA: the problem is that if you load these paragraphs with
    contextual clarification then it starts to get quite heavy

    jar: use your judgement

    noah: legal community have an extraordinary capability for
    this, clarity is important

    JeniT: already talked about tightening up terminology -- so we
    can skip over that section

    <timbl> "For instance, one standard set of terms and conditions
    includes" -- reference?

    noah: "not taking into account this complexity" -- is this a
    bad thing?

    JeniT: yes, this is an example of trouble
    ... with "distribute", the problem is transfer of ownership
    because there is no transfer

    noah: would be useful to clarify this below the box

    ht: the Guardian has this profile thing where they put
    ... you could use little anchors to highlight or signal
    problems in the text
    ... this is a great way to show where the problems are, to make
    people realise that standard boilerplate is full of gotchas

    noah: might be worth picking the problem apart

    JeniT: would you say that throughout the entire background, it
    would expand it

    ht: I was thinking mostly about the box examples

    jar: might be nice to have a couple sentences after each
    example to explain what is an example about it

    Larry: can you use a different style for examples?

    RB: you can use class=example

    noah: this is fine, we can refine style

    JeniT: used blockquote to indicate them

    timbl: when you quote gsip.com, is it possible to use a copy of
    their T&C since it may not be stable

    <noah> Propose after box on scraping: "Yet, the automated
    agents on which the Web depends are incapable of reliably
    understanding such written licenses."

    jar: you can't even mention aa.com, so you couldn't cite the
    source properly

    noah: paragraph that says "limits placed on use of a
    website"... suggest that after that, you put [pasted above in
    ... you don't want to fix this, NLP is not an option
    ... explain why deep link paragraph is a problem

    JeniT: similar to previous comment

    noah: happy to skip if you feel you've got that for all
    ... the SHOULD not be misleading part â something about the
    different between SHOULD and MUST ought to be clarified

    jar: this is legal language

    noah: right, which may be different from RFC2119

    jar: should we include reference to 2119 in terminology?
    ... I don't think it's implied that everything in the box is

    noah: it's fine if it's clear that these are just examples of
    things we need to talk about
    ... wonder if scope should move up, to establish expectations?

    JeniT: Publishing section
    ... 3.1 Hosting

    noah: paragraph1 too strong, trying to say it's not a proxy
    ... but is confusing

    timbl: what do you mean by that?

    JeniT: it's not a copy of something that's being hosted
    somewhere else
    ... trying to separate out the case where this is the original

    noah: if we have a photograph, hosted on her website
    ... I want to copy it (with permission); now we're both hosting
    ... but with your definition I'm not

    JeniT: here we really want to talk about the original, not the

    timbl: I disagree, if you set up software on your server you're
    serving pre-existing content, not the original but you're still
    hosting it

    jar: delete the notion of "original"

    <noah> Section 3.1, suggest:

    ht: the two cases I am concerned with are those in which jailed
    infringer is said to "just link" to content

    JeniT: he was embedding it

    <noah> chg/does not necessarily mean that the organisation that
    owns and maintains the server has an awareness of that data
    being present/does not necessarily mean that the organisation
    that owns and maintains the server has an awareness of the
    details or intended meaning of that data./

    <noah> Reason: surely it's aware of the bits.

    JeniT: but he was not hosting it

    ht: "just linking" conjures up the notion of clicking, a user
    ... so we need to be clear that hosting here covers that case

    noah: my ISP knows what files I've put there

    ht: no they don't
    ... "know" is not a helpful word

    noah: they shouldn't be asked to find out if you have child

    ht: they know a whole lot less than that

    timbl: two types of know 1) is are aware of it as a matter of
    business, and 2) could find out if they paid someone to do it

    JeniT: has "specific" awareness?

    ht: ok

    <Larry> to what extent does provenance help ?

    [discussion about Wendy]

    noah: we should check the awareness issue with her

    <jrees> a to-do (after Dijkstra): check verbs to consider
    appropriateness of automata or documents being active agents,
    replace when appropriate with people or organization (e.g.
    "server being aware" to "server operator being aware")

    noah: would like this paragraph to dig deeper into the
    difference between knowing that data is there and knowing its

    JeniT: I understand the comments, will rephrase

    Larry: does the work on provenance help here?
    ... were you to record provenance, could you push
    responsibility back to originator

    jar: out of scope

    <noah> Noah notes we're run off the end of the parts he's read

    Larry: why is it out of scope?

    jar/robin: because the technology is not there

    Larry: but to what extent *could* this be useful? Ask the
    provenance group?

    JeniT: maybe this could go into section 4 since it's about

    <ht> "any specific awareness of that data being present, much
    less of its nature." would do it for me

    Larry: the TAG has more influence over W3C and its groups than
    web page hosters

    ht: there's a WG

    [meta discussion]

    JeniT: would like to come out of f2f with plan forward, not
    just publishing but also potential CG

    ht: would anyone object to FPWD at this stage, assuming Jeni
    takes comments into account?

    Larry: so long as the abstract is clearer on next steps I would
    be fine

    <Larry> my only concern is that the introduction makes it clear
    that we're open as to next steps

    JeniT: let me try to draft something and when we come back on
    Wednesday we can figure that out

    <Larry> clearer that 'next steps' are open

    noah: so no one likely objects to FPWD, how much do we need a
    longer session?

    [no objection]

    noah: anything other than actions?

    ashok: yes. the idea here is to influence the legal ecosystem.
    ... publishing it as a finding will not do that
    ... a Rec is not enough either
    ... it's not sufficient

    jar: you need publicity

    ashok: need to involve a broader community

    jar: won't be hard to sell, if the EFF learns about it it will
    be pushed

    ht: we will work to push this in public outlets

    noah: take an action long term on getting this on policy radar?

    Larry: we need to get to a position that people who have a
    stake in this game can voice their opinions, concerned about a
    TAG Rec

    <Larry> i'm concerned that we establish a next step process
    which actually engaged in discussing the content

    noah: so you're saying that some of the relevant people might
    not be comfortable with www-tag?

    Larry/ashok: yes

    noah: we'll talk on Wednesday about next steps

    Larry: want some feedback from relevant community, not sure how
    politically sensitive this is

    JeniT: please email further comments


    noah: there will be a short session on this on Wednesday



    <JeniT> ScribeNick: JeniT

    noah: welcome to Robin

Web Applications: Privacy by Design in APIs for Web Applications

    noah: Product page is no longer a draft:
    ... review of

      [45] http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
      [46] http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis-2012-03-27

    robin: the feedback I've got is that the scope should be
    ... so I will clarify it here
    ... the background is: we started working on Geo API
    ... this had privacy impacts
    ... in DAP we tried to take into account privacy from day one
    ... DAP started to think about how to do privacy in APIs
    ... one principle was API minimisation which led to DKA's draft
    ... now, that is only used in one API
    ... and not used in any other WG
    ... because we've moved on to other techniques
    ... so API minimisation needs to be set into a broader
    ... applicable to several groups who are defining APIs

    <Zakim> DKA, you wanted to ask robin to put the good parts back

    DKA: that all sounds great
    ... *but* I think you've taken out bits that shouldn't have
    been taken out

    <DKA> [47]http://www.cs.virginia.edu/~evans/cs551/saltzer/

      [47] http://www.cs.virginia.edu/~evans/cs551/saltzer/

    DKA: for instance, the original draft referenced Saltzer &

    jar: in academia, this is the seminal classic on the subject

    <DKA> [48]http://escholarship.org/uc/item/0rp834wf

      [48] http://escholarship.org/uc/item/0rp834wf

    DKA: I understand why you might not want to bring those things
    ... but I think it's important to do so, to mend the fence
    between the "privacy nuts" and the "script kiddies"
    ... there is really good information in the Dierdre Mulligan
    ... and in the Saltzer document
    ... these are architectural principles that could be brought
    into the modern age

    <jrees> Official but paywalled location of S&S's classic:

      [49] http://dx.doi/org/10.1109/PROC.1975.9939

    DKA: if the additional techniques that you think could be
    recommended enhance these
    ... then point that out
    ... point out that it helps to minimise the data that flows
    down the line
    ... I would like that work, which I think is good, to be
    brought through

    robin: I hear that the digestion process was too aggressive

    DKA: you know the latest stuff from DAP
    ... have the principles been tossed out?

    robin: mostly the document from which they come has not been
    updated in three years
    ... no one has read it in two years

    DKA: did they need to be updated?

    robin: I don't have a problem with the meaning of the
    principles, but the phrasing is probably off
    ... because the discussions have happened in other WGs
    ... and whenever the document has been cited, it's been ignored


      [50] http://dev.w3.org/2009/dap/privacy-reqs/#privacy-minimization

    robin: so clearly it's not expressing things in a way that
    people are able to use it
    ... I'm happy to try to revive those principles more actively,
    but we need to rephrase them
    ... and I'm happy to do that
    ... I really tried to make this document a how-to manual for
    people busy writing specs
    ... so if I'm writing a spec, what do I need to read to get it
    ... a short, checklist document
    ... I could re-organise the document so it serves both ends
    ... there's good architectural matter in the documents you
    ... so I will try to restructure to serve both documents, I
    think that's doable
    ... the fast reading for the spec writers, and then there's the
    background that can inform further thinking

    DKA: yes, and give the reasons for why the techniques work

    ashok: when we started this work, we really wanted to do
    something in the privacy area
    ... DKA found this well-scoped, well-defined area, which he
    wrote up
    ... and we hoped we could close on it quickly
    ... what I'm worried about is that the scope has been enlarged

    robin: slightly

    ashok: the parts that you've added are different
    ... they seem to be addressing a different problem with
    different solutions
    ... it looks like two ideas in this space, and I'm not sure
    whether we shouldn't break them up into two things

    jar: or there might be more, two is a funny number

    ashok: there's lots of issues in privacy, and we couldn't
    possibly handle them all

    robin: I don't want to boil the privacy ocean
    ... this document is scoped to what you can do about privacy
    inside a User Agent API
    ... it's not everything that could possibly do in this area
    ... but I think it does scope the problem in a way that is
    useful and applicable by people who are working in this space
    ... and it would be difficult to explain them in isolation

    ashok: so these are two directions that a user agent could take
    to help protect privacy

    <Zakim> noah, you wanted to talk about tradeoffs

    robin: not the user agent, but the design of the API to be run
    within the user agent

    noah: this is good work
    ... I think it's coherent in its scope
    ... I'm worried about it taking a long time, so focusing on the
    most important thing is a good idea
    ... you were saying that you wanted to do a quick guide for
    people building these things
    ... I think the TAG is at its best when it tries to tell
    stories that have longevity
    ... there are tradeoffs in the designs of the APIs
    ... I'd expect to see those tradeoffs set out, for example how
    testable the API is
    ... as it will have a bigger surface area

    <Larry> I don't think this is the right recommendation for
    "privacy by design". I'm not certain privacy-by-design if only
    because there isn't even a clear definition of the "privacy"
    design goal. I think this is consistent, I was worried about
    API minimization. Note GEOPRIV policy document
    [51]http://tools.ietf.org/html/draft-ietf-geopriv-policy-25 in
    25th revision

      [51] http://tools.ietf.org/html/draft-ietf-geopriv-policy-25

    noah: also talk about performance
    ... numbers of calls on the API
    ... draw out the core things
    ... to teach people to think deeply
    ... handy guides are great as well
    ... but I'd skew it more towards longevity

    <Zakim> timbl, you wanted to feel that a document of this sort
    should mention acceptable use tracking, and the concept of
    accptabl euse for a user aget and fo a community of agents of

    timbl: basically, I think it's a very useful document
    ... two separate things that occur to me
    ... talking about acceptable use
    ... that's what came out of a privacy workshop at MIT
    ... about capturing policy
    ... if you're a user agent, you don't want to do anything
    unexpected or damaging
    ... if I've decided to share something (eg a calendar entry)
    ... I select the two people to share it with
    ... my app might decide to send them emails
    ... it would be more reasonable for it to pop up the email so I
    can edit it
    ... it's different to add the name & address to a mailing list
    ... which leads to the idea that sometimes there's an implicit
    ... you haven't captured what you said the data could be used

    robin: looking at data usage is a fundamental question in
    ... but it's hard to put that into API design
    ... but you'll get pushback from API designers
    ... and you'll get a fight, and it won't give progress

    jar: can we learn from that conflict?

    timbl: the related thing is between a trusted and an untrusted
    ... web apps have to have total power, so they become trusted
    ... with an untrusted app, it's difficult to stop them from
    using the data for something different
    ... but then there's a trusted app talking to an untrusted app

    <Larry> note long discussion about whether SPDY's use of SSL
    offers a "promise of improved privacy"

    timbl: at that point it might be reasonable to have a
    negotiation about acceptable use
    ... because the trusted app gathers the data to do something

    robin: it would make sense, but we don't want to reinvent P3P
    ... DAP started looking at rulesets, a simplified version of
    ... so a server could say what it wants to do with the data
    ... there's only one person in the privacy community who cares
    ... and no one in the browser space
    ... no one sees how to make that work in the broader sense
    ... the solution we've come up with at the moment is user
    ... so web intents allow the initiation of communication
    between a server you trust and another that you don't
    ... or vice versa
    ... with the user in the middle saying ok about the transfers

    <Zakim> DKA, you wanted to comment on scope

    <Larry> main problem is that the design requirements for
    privacy, accessibility, performance, security from
    eavesdroppers, etc. can't be evaluated in isololation, so "X by
    design" in general is problematic

    DKA: I want to comment on scope and support Robin
    ... the original idea we had for privacy on the TAG was data
    minimisation as one targetted document as a series of things we
    could say
    ... I struggled to think about what that set should say
    ... your revised title and scope for this document really made
    sense to me
    ... how do you apply the 'privacy by design' idea to API design
    ... I have been thinking about this for a while, and this
    brought that back to me
    ... so I support that idea



    DKA: and I think the scope you've chosen is not boil the
    privacy ocean
    ... it's focusing on the API design, rather than all the
    potential issues that the TAG might hit on privacy

    robin: yes, and it stops where the IAB's work on privacy starts
    ... the IAB works up to the protocol layer
    ... and I hope their work will also address data usage

    larry: I'm really concerned about the TAG taking this on as a
    work item
    ... not because it's not important, but because we're
    optimising about a moving set of requirements
    ... we had a discussion about SPDY's use of SSL and found we
    didn't really have a common understanding of what privacy meant
    ... we're optimising against a goal that is not clearly
    understood in the industry
    ... the GeoPriv policy expression language has been repeatedly
    ... the subject is controversial enough and has a lot of
    different perspectives
    ... it seems unlikely that the TAG will converge on a finding
    that will fit with those
    ... especially as the IAB is moving about what it covers
    ... we have the area of variability around the tradeoffs
    ... and about the definition of privacy and the channels of
    ... and then there's the boundary between this and other TAG
    ... the boundaries feel very fuzzy to me

    robin: you're worried about us broadening the scope?

    larry: we have a risk of overlapping and saying something
    contradictory, or leaving a gap between this work and others'
    ... to shallow to the point it's not actionable, or too deep

    yves: what about the risk of saying nothing?

    larry: what's the boundary between the TAG and the privacy
    interest group etc
    ... there are other groups who are strongly chartered to work
    on this

    <Larry> wonders if we are really ready to negotiate a boundary
    with IAB

    larry: maybe we could come up with something that's shorter and
    more generic to encourage further work

    robin: we should talk about this in the session with Dom
    ... I did meet up with Christine who is chairing the privacy
    interest group
    ... to discuss whether this is of interest to them, whether
    they should be doing it, whether the TAG should be doing it
    ... I've also been talking about it with the IAB as well


      [53] http://tools.ietf.org/html/draft-iab-privacy-considerations-02

    robin: the reasonable consensus is that the IAB are working at
    the protocol level
    ... and I have the impression that they are happy with this

    noah: isn't there a lot of conceptual stuff that has to be
    sorted out across these

    robin: yes, so we've spoken about terminology
    ... which is still a moving target

    noah: do they include a threat matrix?

    robin: they start with an internet privacy threat model

    noah: that seems important to agree on, what the problem space

    robin: yes, so their terminology is too much of a moving target
    to be reused, so that will need to be revisited at intervals
    ... as far as the Privacy IG goes, Christine felt that some
    joint work, either joint review or a joint TF
    ... to look at policy and that we could contribute
    technological view

    larry: I talked to people at the IETF meeting, to the IAB, to
    Wendy, to Thomas, and they didn't mention any of this
    ... for you to have a private discussion, that the others in
    the IAB and Privacy IG aren't aware of makes me worried

    robin: these discussions happened Thursday and Friday

    larry: we need to arrange discussions with the IAB in order to
    collaborate with them

    noah: getting colocated with the IAB has proven difficult
    ... we couldn't have a TAG meeting at the same time as the IETF

    larry: my concern is about overlapping with other groups

    <Zakim> jar, you wanted to urge disclaimer about sampling of
    techniques, it's not a comprehensive treatment

    jar: there's something that feels incomplete about the draft
    ... about how the scope is set
    ... if you just look at the title it looks like it's about all
    privacy issues
    ... what you've said today about the scope is really important,
    and should go into the introduction
    ... this is really just a sampling of things that have come up
    through the WG process

    timbl: you could have a related work section

    jar: there's a lot of interesting stuff in this space
    ... you should say that

    noah: say why we chose these bits now
    ... and what you should watch out for because we haven't
    covered it here
    ... stuff that hasn't been touched: different threat models,
    different capabilities

    jar: give space for the reader to realise that this is a
    sampling of what we know about right now
    ... it might end up being complete, but because it's an active
    area it's unlikely to be

    robin: this is like a BCP more than anything else

    noah: it might just be early
    ... a year ago people were talking about minimisation

    timbl: I like 'patterns in API design'
    ... and you could mention an anti-pattern, things that you
    didn't cover
    ... you're not saying they're best, that they could work for
    some people

    robin: the reason I didn't use 'pattern' was that several
    groups said it would tie it to 'design patterns'
    ... which is a little old-fashioned
    ... personally 'pattern' would have been something that I would
    have used, but some people are scared of using that word

    <Zakim> noah, you wanted to say we must be willing to say we
    don't have good answers on, e.g. policy

    robin: I'm happy to try using it

    <timbl> Alexander et al A Pattern Language

    <timbl> 1865

    noah: talking about policy, and that we don't have good answers
    ... there's a risk of telling the piece of the story we
    understand in isolation
    ... and perhaps without policy it doesn't matter
    ... need to explain which part of the problem these designs
    will solve



    noah: and what issues it doesn't solve
    ... if it can do it without talking about policy, I'm happy

    robin: I think that's part of explaining the scoping better

    noah: let's see if we can tell enough of the story with this
    ... we have another session on this tomorrow to review how this
    went with Dom
    ... and we can go over logistics at that point
    ... so let's wrap this up for now and come back on it tomorrow


Summary of Action Items

    [NEW] ACTION: Henry S to prepare TAG discussion of
    gs-04 - Due 2012-04-17 [recorded in
    [NEW] ACTION: Jonathan to suggest to TAG sections of HTTPbis
    specification that TAG should review - Due 2012-04-17 [recorded
    in [57]http://www.w3.org/2001/tag/2012/04/02-minutes#action03]
    [NEW] ACTION: Noah to schedule (soon) TAG telcon review of
    gs-04 - Due 2012-04-17 [recorded in
    [NEW] ACTION: Yves to figure out who might be a good choice to
    present Hybi (and as appropriate WebSocket protocols) to the
    TAG [recorded in

      [55] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04
      [58] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04

    [End of minutes]

     Minutes formatted by David Booth's [61]scribe.perl version
     1.136 ([62]CVS log)
     $Date: 2012/04/06 19:34:47 $

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

============3 April 2012 =============


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

                                - DRAFT -

                Technical Architecture Group Face-to-Face

03 Apr 2012

    See also: [2]IRC log

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


           Robin Berjon, Tim Berners-Lee, Dominique Hazaël-Massieux
           (in part), Yves Lafon, Ashok Malhotra, Larry Masinter,
           Noah Mendelsohn, Jonathan Rees, Jeni Tennison, Henry S.

           Peter Linss

           Noah Mendelsohn

           Tim Berners-Lee, Jeni Tennison, Henry S. Thompson


      * [3]Topics
          1. [4]Web APIs and security
          2. [5]Web Applications: Security and Web Applications
          3. [6]URI comparison
          4. [7]WebApps Storage
          5. [8]Mobile threats and opportunities
          6. [9]Administration
          7. [10]XML Error Recovery
      * [11]Summary of Action Items

Web APIs and security

    JAR: I know what Adam Barth is up to, SES people are up to

    Noah: Robin and i exchanged email.

    Noah:My previous experience was that web apps have been less
    successful than I had hoped. I got this music catalog though
    the post, with "ios rocks" in the music catalog -- an amazing
    list of ting s people are building with native apps. Like a
    mixing board with ipad dock and the software on the ipad. This
    needs a proprietary hardware connector for example. 6 channel
    streaming recorder, effects pedal, etc. so you need low-level
    access to things like DSPs

    Robin: That is access to the core audio API.

    Yves: Actually for audio you can do all the processing in JS:
    it is a question of latency why you need core audio.

    <masinter> aspects of native: (a) performance (b) access to
    APIs (c) monetization (d) trust

    <masinter> maybe (b) and (d) are related? vendors link (b) to
    (c) because platform vendors take percentage

    <masinter> (a) performance = throughput but also latency

    Noah: A risk of de-facto standardization around a particular

    TimBL: An RDF client library has to be aware of 303s etc, so
    that it understands the right relationships between things. You
    must be able to write code which will work in trusted and
    untrsuted Apps, write once runanywhere. When running as a
    script (untrusted) rather than Firefox (say) extension (trusted
    code) it must be the same RDF library. In Extensio mode, it's
    omnipotent, otherwise in script mode it is very constrained.
    But the API must be bascially the same. If you violate the
    cross-site-scripting attack checks in a browser, at the moment,
    there is no error code, no error message, so it is really hard
    to invoke code conditional on and in adaptation the untrusted

    TimBL: When I tried this there was no error code or exception.
    I raised it on the list. The response I got is "it's really
    important not to give a response, so the app can't phish to
    find out what's possible. And trusted apps are not a goal."

    TimBL: Two points: 1) I think it's distressing to have a system
    that doesn't help you debug; 2) the system has to be capable of
    running in a trusted mode where you're sure you'll get some
    kind of response, either success or error

    JAR: Seems analogous to Noah's point about access to the
    hardware port

    Noah: Yes, except the port access stuff may be harder to make
    portable if the ports are proprietary and different

    <masinter> air & phonegap ([12]http://phonegap.com/) are
    examples of 'native app' development tools which allow writing
    apps as both webapps and native

      [12] http://phonegap.com/

    TimBL: A lot of people have assumed there will be shades of
    gray between fully trusted and untrusted apps. Seeming like
    some people are feeling the middle ground may be too hard to
    work out. The architecture which is emerging has only the two

    JAR: Do you, Tim, agree that the middle ground is unlikely to
    worth working toward?

    TimBL: Seems like a research project. I'm interested in the
    TAG's position on the question: should APIs always give good
    responses for both trusted and untrusted apps?

    jar: The question is, is there any middle ground between the
    completely trusted and untrusted app. Orthogonal question, can
    you design APIs which work in either situation? There are two
    general approaches on the table, from 50km view. One approach
    is origin case, origin(module) defines power of module, links
    to CORS design and Adam Barth's academic work. The other design
    is you get power by being passed it as a parameter. This is a
    30 year old ACL vs Capability argument, we should not get into
    it now. People are polarized. In Tim's example, using XHR, you
    are saying 'here is the URL' and later getting a response
    callback, or your callback just doesn't happen in the bad case.
    In the origin case, you would use the origin of the module to
    decide whether to authorize the delivery of the error code to
    the XHR caller.

    Robin: The origin is the one -- the HTML page -- which involved
    the js, not the actual URI the js was loaded from, which is
    irrelevant/not tracked

    Robin: The js is not namespaced -- anything can put callbacks
    on anything, no boundaries.

    jar: Javascript's kind of like Java -- The aim is "write once,
    run anywhere".

    NM: Well, Java has a pretty elaborate class loader model that's
    pertinent to how Java code is loaded and gets privilege

    jar: java security was a disaster -- based on call chain --
    like the origin system

    jar: in the capability method, you have a param you can pass
    which gives you the right to do things and you pass it to the
    ... there is intense pressure to make js apps work and access
    things for which you need privs

    Dominique Hazaël-Massieux joins the meeting

    dom: a lot of the topics you have been discussing may be very
    relevant to what I will present

    jar: personally, i find this the way to think about it -- it is
    a question of privs and to whom they are granted. There are
    more than two priv levels -- in fact there are many levels --
    it might have access to the net but not the core audio for
    example. In fact there are questions of to what inside the app
    it is granted -- not the whole app, as now.

    <Zakim> darobin, you wanted to point out that there is some
    possibility for APIs in the grey areas as well; point out new
    work; different design for trusted APIs and to say that SES

    <Zakim> noah, you wanted to talk about shared libraries

    Robin: many things to say

    Robin: 1) w3c has sent out announcement that it is looking into
    new work for system level APIs -- see member only


    dom: The device API meting is open and discussed this

    robin: When you design APIS which work inside the browser
    security model, the API looks very different from something
    done with full trust access. There is investigation of new work
    area for APIs specifically for completely trusted APIs

    Robin: 2) even if we take the very simple binary on/off trust,
    there is some room for grey area.

    Robin: The example for the XHR where you want to not give error

    Robin: In firefox, you double-click the tab and it makes it an
    installed app.

    tim: really?

    Robin: Concept of installed apps. They don't have to have
    high-level apps, you can give them specific privs -- greater
    local storage, system notifications, getting error messages
    could be some

    Robin: [Who said this? RB, tutti to check] Most of what I
    wanted to talk about can go into DOM's session

    Robin: [Who said this? RB, tutti to check. JAR thinks Dom said
    this.] SES are not a solution to the trust issue

    jar: you mean security

    Robin: They intermesh -- SES allows you to bring in 3rd parties
    which operate inside a limited space without access to each

    Robin: [Who said this? RB, tutti to check. JAR guesses Dom] All
    policy based systems which don't plug the XSS hole are really
    threatened by that hole

    jar: SES doesn't give you a notion of what things [principals]
    have what authority in running code - you have to say, (like in
    Powerbox etc. and ongoing work) how you [? collect the query -

    TimBL: This isn't just about trusted apps. I use the same code,
    server side, and on the command line, including for test
    harnesses. I want all that to run my AJAX code. This needs to
    be part of normal computing. So, it's not just trusted and
    untrusted apps in the browser, includes things like node.js on
    the command line and server side.

    <darobin> [14]http://www.phantomjs.org/ -> PhantomJS, run a
    browser on the command line

      [14] http://www.phantomjs.org/

    <darobin> [15]https://github.com/tmpvar/jsdom -> JSDOM,
    emulation of a browser environment in NodeJS

      [15] https://github.com/tmpvar/jsdom

    TimBL: Also... when you download software modukles from
    different people and representing different people, we'll need
    the concepts of agents running on behalf of completely
    different entities. We will have to surface remote entities as
    first class principals withing the system. Like having Adobe
    have an account of my system with the privilege to update its
    own apps.

    TimBL: If I install a bunch of stuff like
    /application/microsoft, I'm willing to give Microsoft certain
    rights to e.g. update code in that part of the space. I'd like
    to know what rights I'm giving them. I think the origin
    represents this legal entity in an obviously broken way. Maybe
    some Un*x systems will go some way toward associating origins
    with such points in the filesystem trees.

    jar: I think you have to specify the granularity of the grant
    of authority -- is it object, function, program, etc

    ashok: how can I as a user give this authority to an app?

    robin: unsolved problem.
    ... Policy of a rathole to fall into. [? RB to check]

    jar: what about Powerbox?

    robin: later
    ... My personal take e [? RB to check] is a hard-to-get-through
    process you can't do by mistake.

    dom: at the moment you can buy stuff on the web no review

    Noah: We are out of time.

Web Applications: Security and Web Applications Permissions

    <noah> 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-03-27 -- OPEN


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

    Noah: Note the change in order from the published agenda, this
    brought forward from 10:00 today

    <dom> [17]http://www.w3.org/2012/Talks/dhm-tag/

      [17] http://www.w3.org/2012/Talks/dhm-tag/

    Dom: [ presents a talk of 16 slides]

    Larry: Isn't monetization also a driver for native apps?

    dom: Phonegap is addressing that, but I don't thing it is the
    biggest driver
    ... We also are looking at payment in the W3C headlights
    ... [edits slide 2 to add Monetization]

    <darobin> FYI I proposed an approach to modularisation for
    features, but there was no interest:

      [18] http://w3c-test.org/dap/proposals/request-feature/

    jar: For privacy with camera, how about confinement?

    dom: basically impossible

    jar: confinement being limiting the ability of the app to send
    any data back home

    dom: Interesting to explore this approach though
    ... [slide 6]

    robin: recommend panopticlick

      [19] http://panopticlick.eff.org/

    anon1: [identity suppressed for privacy reasons] I see [from

      [20] https://panopticlick.eff.org/

      Your browser fingerprint appears to be unique among the
      2,119,594 tested so far. Currently, we estimate that your
      browser has a fingerprint that conveys at least 21.02 bits
      of identifying information.

    [discussion of fingerprinting details]

    <Ashok> Hmmm... I got exactly the same message from

    <darobin> [21]http://www.mozilla.org/en-US/b2g/ -> The B2G

      [21] http://www.mozilla.org/en-US/b2g/

    <darobin> [22]https://www.tizen.org/ -> Tizen Project

      [22] https://www.tizen.org/

    <darobin> [23]http://www.w3.org/community/coremob/ -> Core
    Mobile Web Platform CG

      [23] http://www.w3.org/community/coremob/



    <jrees> RSA Conference 2011 - Making Security Decisions
    Disappear into the User's Workflow - Alan Karp

      [25] http://www.youtube.com/watch?v=POA8SLCT5EY&noredirect=1

    <masinter> [26]http://www.w3.org/2010/api-privacy-ws/

      [26] http://www.w3.org/2010/api-privacy-ws/

    <jrees> here's Karp's tech report

      [27] http://www.hpl.hp.com/techreports/2009/HPL-2009-341.pdf


    Robin: this is how web intents basically works. You have a
    service page which defines an action, like Pick. Picking a set
    of contacts from the addressbook for say sending an email. The
    service definition declares what it can do, pick a set of
    contacts. Then the user agent registers this service, modulo
    user input (?TBD (chrome people think it can be registered
    without UI)) RB to check

    Robin: You then have a client page. Suppose you have a game --
    you don't give the game full access to the entire addressbook.
    You just want access to it to be given to a set of people. The
    client page says "Start activity... pick contacts" and includes
    a button which the user must press on. This pops up a dialog to
    chose which service. Then it instantiates the service page on
    the side [in an iframe?] and you pick your contacts, and the
    contacts are returned to the original page. RB to check

    jenit: Who defines which fields are actually transferred?

    robin: The service page just gives a URI identifying the
    action, and one identifying the "type" which is a random
    semantic-free parameter used just as a filter

    ______ [break] _____

    Dom: Right now, policy considerations are all at the browser
    level -- ability to access a website is granted indefinitely

    Ashok: You asked about geolocation -- that uses policy?

    dom: In a browser-dependent way - it all depends on whether
    user has granted it many times, etc.
    ... this is all left to the browser

    Ashok: Not to the user?

    Dom: For geolocation...

    Ashok: Can you as a user author a policy?

    dom: you can revoke access for a given website. There is no UI
    for it, there is no policy API in the web browser. In device
    APIs, we really did explore that space quite a lot. They could
    see the long term value but ...

    dom: Some talk about having a generic application-wide policy,
    like CIA want to prevent location ever being available

    dom: [slide 9/16]

    Robin: The ideal is for the user to make an informed decision
    without thinking 0.5 ;-)

    jar: what info is not sensitive?

    larry: sometimes a problem is one person giving away info
    sensitive another person. Like mentioning their name and email
    in the same sentence.

    larry: [Who said this? LM, tutti to check] We can't just
    restrict heis [?] talk of privacy to a user's own information

    larry: When geopriv talked about privacy policy, they ended up
    with a API extension which insisted on passing a policy and a
    timeout with every API call

    dom: I am not saying this is the solution, I am just pointing
    out what is out there

    larry: Consent, opt in and opt out .. we should look hard at
    the assumption that assent helps.

    ht: I am personally in the "always run virus check" mode for
    anything I install, as I had a terrible experience with a bad
    download once.

    ht: there is nothing comparable on my phone which allows me to
    look at any web app, look at the Javascript, and figure out
    whether it is a bad one.

    <jrees> [28]http://www.veracode.com/ ???

      [28] http://www.veracode.com/

    Noah: Different - viruses you just look for signature of
    particular hacks, on js in general, you can't just look at the

    tim: Codepath tracing is getting pretty sophisticated, and
    maybe in the future you might be able to

    robin: There is a crowd-sourced database of known bad web apps

    timbl: Some kind of "Nutrition Facts" for what apps do for you
    would be a great addition to the add-on store, as it would
    remove the "after that a free-for-all" problem.

    Noah: Different users might care about different things

    robin: The android UI is generally regarded as horrible

    <darobin> [29]http://i.imgur.com/JWEII.jpg -> screenshot of the
    Android permissions dialog

      [29] http://i.imgur.com/JWEII.jpg

    tim: Maybe with some rethinking it could be better,
    particularly if it makes promises about what the app will do
    rather than talk about the low-level access the app is allowed.

    larry: We don't have a vocabulary for trust. I would like to
    see use cases; we have stories that we should collect together,
    then analyse them.

    tim: We've been doing that within MIT for 10 years. Anyone who
    tries to make an algebra of trust is making a big mistake. They
    don't match the real world. Trust systems have to connect to
    the real world, and therefore has to be a semweb application. I
    want to be able to say that my coworkers can access something,
    that the DIG blog could be commented on by friends of friends
    or who had attended a particular conference. I don't want to
    have a Google Circle to drag them into. You have to connect
    trust to reality, which is what the semantic web does.



    larry: I was complaining about the word 'owner' to talk about
    meaning, because we don't have a good notion of identity. In
    order to talk about trust, you have to have a model of
    identity. If there's a problem defining the owner of a URI, or
    the namespace of individuals, perhaps we create a namespace of
    identity by projecting owners. You provide identity by saying
    which URIs they control.

    Larry: maybe we could identify principals by the URI [domain
    names, email ids etc] they control

    timbl: That's OpenID. It identifies you as the person who has
    write access to a given page.

    robin: and BrowserID identifies you through an email address

    timbl: and WebID does the same thing [URI you control]

    <masinter> I wonder what is the identity of "browser vendors":
    product safety evaluations

    Larry: This is like product safety. Cars that you can drive off
    a cliff aren't unsafe. There's an assumption that asking
    permission where people understand the permission is better
    than one where the permission isn't clear. Perhaps these are
    like product safety ratings. Are we looking for PICS extended
    to apps, as we talk about rating and validating?

    robin: That could be done in the ecosystem, but not at this

    larry: The stuff about what apps gets into the app store

    robin: If you have a policy-based system; that's the question
    we have to ask first

    dom: Out-of-band curation is one possible approach. I think
    we'll see multiple approaches. There isn't a shared
    understanding within the WGs about what will work for the Web

    robin: Or what the stories are, what the problem spaces are,
    what the terminology is

    larry: The stuff about origin is also a matter of trust. A
    matter of brand. I trust my bank, and things I download from my
    bank. Brands give you trust

    dom: I agree that origin is related to brand

    larry: There's something about PICS we don't want to repeat, as
    it didn't succeed. But we can't avoid it by just saying we're
    not going there

    dom: I don't think any of us know where exactly we're going. I
    think the TAG, as involved with ,cross-group, cross-technology
    issues should be helping: To identify terminology, to identify

    larry: I'm trying to map out the space: brand, trust, rating,
    authority. Finding others who have mapped out the space, and
    adopt the framework

    noah: We've often said that the TAG should work in this space,
    but not found someone to do it

    robin: I would like to do this work. The first step, which
    might lead to further work . . . would be to agree on some
    terminology. Which is currently chaotic. It would be very
    helpful for cross-group understanding

    noah: Who else would we have to involve?

    robin: From B2G project, from the Trident project

    noah: Could we do that without starting a Community Group?

    robin: maybe a TF?. I'd avoid a CG because it can be hard for
    members to join. I'd prefer a TF, separate from www-tag

    ashok: A Finding on this would be wonderful. Terminology,
    mapping the landscape, use cases

    noah: We have to work out the initial scope

    ashok: I would go beyond terminology, to use cases and

    robin: Terminology alone won't cut it. first success would be
    to get the right people talking together. include people from
    Privacy IG

    noah: What other deliverables?

    jar: The use case list and terminology mesh very nicely

    robin: I'm happy to do that, and I can get funding to do it

    noah: Does anyone object to this?

    JeniT: how does the privacy draft fit into this?

    robin: I will need to think about whether it should be a
    product of the TF

    noah: From TAG logistics, is it one or two things to track?

    timbl: We could bank what we have, publish it as a Note. get it
    out there

    noah: There's a dated editor's draft available. To publish it
    as a Note, we'd need more sessions

    timbl: We should produce something sooner rather than later

    noah: We were reviewing as first draft yesterday

    robin: I have a bunch of updates to make on it. I'll do another
    draft, and let's see what people think of it then

    larry: I'd be happy publishing it to say "this is our initial
    work on this topic, which we will take forward". My objections
    were about taking it forward as a longer-term effort. In terms
    of RFC categories, it's not April Fools and it's not Standards
    Track. Publishing things early is good as long as the status is

    noah: I'm only worried that people might take it as being
    something the TAG believes

    <darobin> ACTION: Robin to update Privacy by Design in APIs
    [recorded in

      [31] http://www.w3.org/2001/tag/2012/04/03-minutes.html#action01

    <trackbot> Created ACTION-684 - Update Privacy by Design in
    APIs [on Robin Berjon - due 2012-04-10].

    ashok: How does this relate to the bigger Finding we talked

    noah: Robin should scope that larger thing, I think we should
    leave it to him. Draft a product page

    jar: Limited scope for Note as written. I don't see the
    relationship with the other

    larry: I think this is more about an architecture around
    security and permissions

    <noah> ACTION-514?

    <trackbot> ACTION-514 -- Robin Berjon to draft a finding on API
    minimization -- due 2012-05-01 -- PENDINGREVIEW


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

    <noah> close ACTION-514

    <trackbot> ACTION-514 Draft a finding on API minimization

    <noah> ACTION-684 Due 2012-05-08

    <trackbot> ACTION-684 Update Privacy by Design in APIs due date
    now 2012-05-08

    <darobin> .ACTION: Robin to create a product page proposing the
    Task Force on Web Security/Privileges/Trust/etc.

    <noah> ACTION: Robin to create a product page proposing the
    Task Force on Web Security/Privileges/Trust/etc. - Due
    2012-04-17 [recorded in

      [33] http://www.w3.org/2001/tag/2012/04/03-minutes.html#action02

    <trackbot> Created ACTION-685 - create a product page proposing
    the Task Force on Web Security/Privileges/Trust/etc. [on Robin
    Berjon - due 2012-04-17].

    <jrees> Task force on X where X = ? some options: [Web]
    Privilege Grants; Web Trust use cases & terminology

URI comparison


      [34] http://tools.ietf.org/html/draft-ietf-iri-comparison-01

      A percent-encoding mechanism is used to represent a data
      octet in a component when that octet's corresponding
      character is outside the allowed set or is being used as a
      delimiter of, or within, the component. A percent-encoded
      octet is encoded as a character triplet, consisting of the
      percent character "%" followed by the two hexadecimal digits
      representing that octet's numeric value. For example, "%20"
      is the percent-encoding for the

    <jrees> Larry and I agree that
    [35]http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref is
    inconsistent with RFC 3986 view of equivalence

      [35] http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref

    <jrees> and that therefore the strings that are called "URIs"
    in RDF are not really URIs

    <timbl> We noted that the HTTP BIS had been changed
    significantly to be consistent with a non-document view of the
    web which it had not started with.

    <timbl> over lunch

WebApps Storage


      [36] http://www.w3.org/2001/tag/2012/04/02-agenda#storage


      [37] http://trac.tools.ietf.org/wg/iri/trac/ticket/111


      [38] http://trac.tools.ietf.org/wg/iri/trac/ticket/113

    NM: Time to get this over the last hurdles


      [39] http://trac.tools.ietf.org/wg/iri/trac/ticket/114


      [40] http://trac.tools.ietf.org/wg/iri/trac/ticket/112


      [41] http://www.w3.org/2001/tag/doc/Seamless%20Applications.pdf

    AM: The above is a discussion document asking us to consider
    whether we should go in this direction

    LM: We could also consider combining this with web vs. native
    apps topic

    NM: [points us to draft product page:


    <masinter> I think there's a strong correlation between local
    storage with backup (for native apps), vs web storage with
    caching (for web apps)

    <darobin> [larry, I think that native or web is orthogonal to
    this problem—issues are about identifying resources
    irrespective of storage location, and the value of
    client/server synch]

    NM: [takes us through the product page]

    NM: Is this roughly in the right direction


      [43] https://www.w3.org/2001/tag/doc/Seamless%20Applications.pdf

    AM: My doc addresses the question of how to write apps which
    would run seamlessly whether connected or disconnected
    ... Three requirements I came up with:
    ... 1) What it requires when it's connected;
    ... 2) Minimum requirement when not connected
    ... 3) Where it might find those requirements

    <noah> I think we need to state the relationship between
    identification and access when connected and when not

    AM: Hints about (3) might be AppCache, IndexedDB, local file
    store, Web Storage
    ... Regardless of how the local information is found, should be
    accessible in a uniform way

    NM, TBL: That sounds contradictory

    RB: By user or by app?

    AM: By app

    TBL: MySQL API and filestore API are different, right?

    AM: Yes, but once you access a particular resource, the API
    thereafter is the same

    TBL: So a resource is for instance a JSON blob

    Tutti: So there are two layers -- a layer of access, which is
    different for different stores, and a layer of utilisation of a
    resource once accessed, which is uniform whereever it comes

    NM: So if the store happens to be a SQL store, access might
    involve joins

    AM: Yes

    <masinter> I'm concerned about error recovery, update conflict
    resolution, etc. when working offline?

    NM: So we don't lose the unique value of the particular storage

    AM: Right

    TBL: Does anyone understand where this is going/why?

    AM: The fact is that there will be lots of different storage

    <jrees> ashok urging shared API for the objects retrieved using
    all the various APIs?

    NM: So once I've got a JSON blob I can do another join

    AM: Not talking about that
    ... Think of this as a calendar app
    ... So suppose you got the blob which is your calendar
    ... as you work with it, you update it
    ... If the app was running connected it would be working with
    both local and global calendar
    ... but if running disconnected, you have only the local
    resource available

    NM: does this require distributed 2-phase commit

    AM: yes

    AM: Once you get connected, you start transactions at both
    levels, back out all local-only changes, recommit them all both
    locally and globally, then complete the transactions

    NM: That requires a lot of mechanism, to support distributed
    two-phase commit, and is typically not nearly stateless.

    TBL: Backing up, 'access' built out of parts, or blob stored

    AM: Let's not go to complex access, e.g. joins, simpler to
    assume monolithic storage.

    TBL: iPhoto stores [in a more complex way]

    NM: I'm pushing on this because I think he's solving the wrong

    AM: If you exploit a particular storage scheme's special
    properties, then you are tied to it
    ... but I didn't want to go there

    HST: I've had this problem: you have a storage problem and an
    interoperability problem. You don't know what provision the
    different Web platforms have. I had to write different shims
    for the different storage facilities across the different
    browsers: cookies, Google Gears or whatever. That's what Ashok
    is trying to solve.

    HST: I understand the problem AM is trying to solve, it's the
    fact that different platforms today support different basic
    offline storage models

    NM: Right, that's just a matter of API design, not a problem
    the TAG needs to work on

    AM: The problem I see is that not all the backends have
    transactions, which my story needs

    JAR: They will

    RB: localStorage won't

    TBL: You can use e.g. git on top of a local filestore. . .

    AM: Moving on -- if the commit described above fails, the user
    loses all their work

    NM: Fails, or there's a conflict?

    AM: Conflict, right -- that's the bad case
    ... Can we say anything beyond "The app has to do what it can"

    NM: There is 30 years of work on this problem

    TBL: Apple Sync Services requires you to declare your object
    type, e.g. Calendar Event
    ... Mostly works, but if you have conflicting values for the
    same field, there's a generic tabular conflict resolution
    display to the user
    ... My experience is that this sometimes happens when I can't
    see any difference in that display, or even when I haven't
    touched the app on the phone at all. . .

    NM: Lotus Notes has application-specific handlers
    ... Default is to make two copies of the relevant unit
    ... Difference between deletion and creation is tricky,
    sometimes handled by 'tombstones', with timeouts
    ... so you can tell the difference between "I deleted, you
    didn't" and "You created, I didn't"
    ... Multi-person, multi-year task and then you don't get it
    right -- we shouldn't go there

    TBL: Another route is to enforce universal undo, so you can
    step back one step at a time

    NM: You're relying on there always being a human available to

    <noah> Right...that's my bottom line. This is the wrong problem
    for us to be trying to solve and, even if it were the right
    problem, the solutions are horrendously difficult, have been
    worked on for 30 years, and would be in the hands of a
    design/development group, not the TAG

    AM: Yes, some DBs to that

    <noah> I would like us to look at one particular problem: when
    I use an application that runs locally and potentially
    disconnected, to update information that we otherwise want on
    the Web, what is good architecture regarding identification,
    and what latitude should be available for implementation?

    <noah> I would like to see a finding that if information is to
    be identified with a URI for use on the Web, then it should be
    identified with the same URI when accessed disconnected.

    Tutti: discussion of various source control systems' approach
    to related problems

    JAR: I agree with NM that there is a huge background wrt sync
    -- is that what we want to work on?

    AM: Is it important for us to be able to write "seamless apps",
    and support others who want to do so

    RB: We are seeing a collection of offline stores being
    deployed, can we get in now to help exploit them responsibility

    NM: If information is to be identified with a URI for use on
    the Web, then it should be identified with the same URI when
    accessed disconnected.

    AM: I asked Raman about this, wrt using GMail offline -- does
    the message have a URI?
    ... He said probably not until it gets online

    NM: I'm not saying it's obvious how to do this, but it would
    have real value if we did
    ... Consider working on an airplane, writing a document and an
    email which points to the document, by its URI
    ... So that when I get online, I synchronize and the email
    ... The email should point to the document online
    ... This is (close to) what Lotus Notes has done for years
    ... This may be too hard, at least in some cases, but it is an
    architectural desideratum

    AM: How can you have the same URI -- you're not on the Web when
    you are on the airplane

    NM: Yes I am -- the Web is not a set of servers, it's an
    information space
    ... I suspect if follows that the apps do any necessary
    synchronization, not the underlying storage mechanism
    ... That means e.g. the JScript in GMail knows enough to create
    URIs in a way consistent with the way those names will be
    created at sync time

    AM: So, is all we can say application-specific architectures
    will exist, or can we say something overarching?

    NM: Well, at least Good Practices, as above, and maybe design
    patterns and even maybe APIs to support them?

    TBL: LDP API work relevant?

    AM: Maybe

    NM: I'm guessing that in practice apps would mostly do the
    syncing, as they do today. There might be some shareable
    infrastructure the emerges to help the apps, e.g for storing
    URI-identified rows in index-DB or SQL and/or tracking updates
    since last connect. I don't think the TAG should spec the exact
    sync protocol or shared facilities. We should make statements
    about how URIs are used. Of course, we need to be sure that
    what we recommend is deployable in practice, and that it meets
    the intended needs.

    TBL: LDP apps use a triple-based API, which is grounded in a
    generic store

    TBL: Interaction between API and store is "fetch/store the
    entire store" or "delta"
    ... That's where sync has to happen
    ... So this would enable a generic approach to sync

    NM: So, where do we go with this?
    ... We've seen AM's proposal, my alternative, and TBL's LDP
    ... Not sure whether LDP is a third proposal

    AM: I think the LDP story goes way beyond NM's approach

    NM: So what story are we trying to tell?

    HST: Do we have a client? Is anybody asking for this? Is
    anybody listening?

    NM: Not as such -- people are building stores, but no-one has
    asked for our advice

    JAR: I prefer RB's "Goal is to try to anticipate pitfalls and
    raise awareness" better than the existing product page's goal

    NM: Yes, if you mean high-level pitfalls, i.e. we are the T A G

    RB: I have these problems today, and don't know where to look
    for help

    NM: As long as we don't try to roll our own

    TBL: Pointing to existing solution spaces

    JAR: Commissioning ourselves to do a report on the problem

    NM: CouchDB guys said they were building on some of the Lotus
    Notes work, e.g. tombstones

    <darobin> [44]http://couchdb.apache.org/

      [44] http://couchdb.apache.org/

    <noah> CouchDB Overview:

      [45] http://couchdb.apache.org/docs/overview.html

    RB: CouchDB is simple, you put JSON docs in, nothing is
    deleted, you access with Map-Reduce

    AM: What can we say generally?

    <dom> [I'm not sure the TAG documenting Web apps sync will
    reach the right audience (presumably Web developers?)]

    HST: I think this is a Vietnam, we should walk away

    NM: Straw poll:
    . . . Nothing: 3+
    . . . Work towards a uniform API, maybe including sync, per
    AM/Product page: 0?
    . . . Patterns/pitfalls: 5

    NM: If we tried to do PaPi (per RB), volunteers?

    RB: I'll review and advise

    LM: As before

    AM: Yes, I'll try

    NM: I'll review
    ... So, clean up the Product page and get started on the work

    <masinter> the product page is meta, not worth spending much
    time on when we can work on the document

    <noah> ACTION-647?

    <trackbot> ACTION-647 -- Ashok Malhotra to draft product page
    on client-side storage focusing on specific goals and success
    criteria -- due 2012-03-06 -- OPEN


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

    <masinter> are we commissioning a study or just a survey

    LM: If we find a survey then this can be simple -- we just
    distil and point

    <masinter> telling people where the cliffs are that they might
    fall off, we don't have to build the guard rails

    HST: I was worried that if JAR's summary, that we need to do
    the survey ourselves is the case, then this is too big a task

    <masinter> the product page is just there to tell people the
    general area where we're working, don't deep end on it

    <darobin> .ACTION: Robin to draft scope and goals for the
    Patterns/Pitfalls work in local/remote storage synch

    <HST> This was not done here, but was done subsequently (telcon
    of 2012-04-12 and is [47]ACTION-693

      [47] https://www.w3.org/2001/tag/group/track/actions/693

    <noah> ACTION-572?

    <trackbot> ACTION-572 -- Yves Lafon to look at AppCache in
    HTML5 -- due 2012-03-06 -- CLOSED


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

    NM: Adjourned until 1600, then DHM on threats and opportunities
    on the Mobile Web

    should update 3986

      [49] http://tools.ietf.org/html/draft-ietf-iri-comparison-01


      [50] http://trac.tools.ietf.org/wg/iri/trac/ticket/112


      [51] http://trac.tools.ietf.org/wg/iri/trac/ticket/114

    <masinter> at IRI meeting last week we resolved to look at

      [52] http://tools.ietf.org/wg/precis/

    <jrees> on break, TimBL, Larry, JAR about whether web spec
    level should be separated from application level and/or social
    good level (?)

    <jrees> maybe s/level/scope/?

    <masinter> conformance vs. social expectation

    <masinter> conformance doesn't require you to do things that
    the social expectation for normal use of the web might require
    you to do

    <masinter> and if you want to create applications that rely on
    conforming properties, you might not be able to rely on the
    social conventions being followed

    [Resuming at 1608]

    NM: Mobile issues, then Admin

Mobile threats and opportunities

    DHM: Two main points
    ... Disruptive impact coming from Web being on some many
    different platforms, but that you can build
    cross-/multi-platform applications
    ... E.g. using web app on phone so that tilting phone reorients
    image on a different device
    ... "Hyper-devices": the Web enables new use of our devices

    <jrees> dom, link to blog post please?


      [53] http://www.w3.org/QA/2011/11/from_hypertext_to_hyperdevices.html

    NM: Blue Spruce at IBM looked at cross-linked browsing

    <noah> Project Blue Spruce may be of interest:

      [54] http://www-01.ibm.com/software/ebusiness/jstart/bluespruce/


      [55] http://www.readwriteweb.com/archives/ibm_blue_spruce_first_look.php

    AM: WebEx ?

    NM: Bluespruce is not shared desktop, but rather a coordinated
    browsing experience in which DOM changes are hooked, and
    broadcast to all participants.

    NM: Linkage at the level of DOM

    DHM: Not sure about the architectural impact, but thought worth
    ... Other area is WebRTC
    ... Real-time peer-to-peer communication
    ... File-sharing as a side-effect
    ... WebRTC is essentially Skype within the browser
    ... Audio-Video comms within the browser is the driving app
    ... Two parts: Access to the camera, mike and audio out;
    peer-to-peer connection
    ... There is a requirement for a mediation server, but there is
    work at eliminating it
    ... There's a Javascript API defined at W3C, plus a UDP-based
    protocol defined at IETF
    ... Two phases, establishing the connection and then actually
    trading data
    ... RTCWeb is name for IETF protocol, WebRTC is the W3C API

    <masinter> [56]http://tools.ietf.org/wg/rtcweb/

      [56] http://tools.ietf.org/wg/rtcweb/


      [57] http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00

    <masinter> The Web Real-Time Communication (WebRTC) working
    group is charged to provide protocol support for direct
    interactive rich communication using audio, video, and data
    between two peers' web-browsers. This document describes the
    non-media data transport aspects of the WebRTC framework. It
    provides an architectural overview of how the Stream Control
    Transmission Protocol (SCTP) is used in the WebRTC context as a
    generic transport service allowing Web Browser to exchange
    generic data from peer to peer.

    NM: Patent problems?

    DHM: Pretty confident at IETF this stuff is safe
    ... But the codec issue is still live, as it must be common
    between the two peers
    ... Some vendors don't want MPEG4 to be allowed

    LM: How far along is codec and transport?

    DHM: Last week at IETF Paris chairs put pressure on getting to

    JAR: Doesn't this raise the possibility of peer-to-peer HTTP?

    DHM: Yes in principle, but not in practise yet, but that's one
    of the potential disruptive impacts that's coming

    TBL: I've always been interested in p2p for HTTP as a tool
    against censorship

    DHM: At the moment the peers have to access essentially the
    same Web page to initiate the connection

    <masinter> note that SCTP vs. SPDY was a hot discussion at IETF

    TBL: Jonathan Zittrain at the Berkman Center at Harvard has a
    project "Mirror as you link" to develop data sharing on the Web

    NM: We haven't yet proven that this approach to p2p maps to the
    existing uses of e.g. bittorrent

    JAR: I was surprised that these two were tied

    TBL: Discovery is a big complex problem
    ... E.g. use a distributed hash table of everyone who is
    looking for a connection

    DHM: There is a whole stack here, with security and encryption
    and so on
    ... Just SSL isn't good enough, to avoid man-in-the-middle
    attacks at the connection initiation time
    ... Because we don't have universal crypto-secure personal
    ... One proposal is to use mutually-trusted shared identity
    providers, such as Facebook, to reciprocally verify


      [58] http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-01

    <masinter> we talked earlier about using "owner(URI)" as an
    identity token


      [59] http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf

    <jrees> The link that LM entered is to a presentation "Media
    Security: A chat about RTP, SRTP, Security Descriptions,
    DTLS-SRTP, EKT, the past and the future"

    <masinter> presentation from last week's RTCWEB discussing keys
    management and RTCWeb security

    AM: Isn't it easier to just encrypt the conversation?

    DHM: But we don't have a deployed PK system on the Web

    TBL: PK doesn't need PKI -- it can be much simpler

    NM: Ray Ozzie did instant group-creation before his company was
    bought by Microsoft, called Groove

    JAR: PKI can be decoupled from the problem, and p2p doesn't
    need the whole PKI as we understand it

    <noah> NM: Groove uses a peer exchange of public keys to
    establish identities, then allows collaboration groups to be
    created across organizations

    NM: Thanks to DHM!


    RESOLUTION: Minutes of 8, 15, 22 March all approved as a fair
    record of the respective meetings

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

      [60] http://www.w3.org/2001/tag/tag-weekly#Admin

    NM: Agreed in the past that we would meet 12-14 June
    ... in Cambridge

    <masinter> does TAG have opinions about W3C process
    -0007/AB_List_of_Concerns-20120306.htm ?


    NM: Our end-of-summer f2f has yet to be scheduled
    ... I will have difficulty travelling in September or for TPAC
    in November
    ... Options include -- yet again in Cambridge, Septemberish

    <JeniT> [62]http://www.w3.org/2012/10/TPAC/

      [62] http://www.w3.org/2012/10/TPAC/

    NM: Another alternative would be a weekend before/after TPAC
    ... although that is in Europe again
    ... Or without me

    RB: Weekend OK but not next to TPAC

    NM: Net-net -- we will wait a while before trying to schedule
    the next f2f after June

XML Error Recovery

    RB: At XML Prague March 2012 a lot of discussion about future
    of XML, XML and JSON, etc.
    ... A panel on XML / HTML issues, chaired by Norm Walsh
    ... There was consensus of interest in a processing model for
    XML that would not halt and catch fire at first well-formedness

    JT: There would be reporting of any error recovery actions to
    e.g. Firebug and/or the console

    RB: The advantage would be that users would not be punished for
    the errors of others

    NM: The scoping to end-user browser scenarios seems too
    limiting. There are other important uses of XML, and the same
    XML that goes to a browser sometimes needs to be processed in
    other ways. Some of the recovery that's safe when presenting
    info to a user is dangerous if the resulting data is to be
    trusted as untainted in a database.

    JT: Not exclusively
    ... Other discussions identified other use cases: editors "of
    necessity" go through states where the documents are not
    well-formed, but a tree-view is still useful
    ... Mark Logic has an error-recovery mode for loading into the
    ... As do some editors
    ... but all of that is idiosyncratic
    ... So the question was if we could have uniform and
    predictable error recovery
    ... across all three use cases

    RB: [libxml pattern] -- same document twice gives same result
    ... Primary use case is in trying to deploy XML to user-facing
    ... The fact that the halt-and-catch-fire experience blows
    that, so browsers have started silently correcting

    JAR: But we know where silent error recovery leads -- it leads
    to HTML5 -- the moving target aspect is really bad

    NM: We can address that by publishing a TAG finding to insist
    on no silent error recovery

    JAR: Errors have to be ugly, to put pressure on fixing them

    TBL: Designing the level of ugliness is important -- the
    console is too well hidden -- show the warning briefly
    ... and allowing it to be configured to persist, for instance

    RB: So that discussion led to a W3C Community Group, with Anne
    van Kesteren editing his earlier XML 5 draft, but the work
    product will not be called XML 5
    ... This is not going to run at breakneck speed, but will work
    its way along

    AM: Does Mark Logic have a patent in the area?

    JT: They use the schema to help, I don't know about a patent

    HST: There's prior art . . .

    <Zakim> noah, you wanted to comment on Robin's proposal and to
    discuss why use cases matter and why standardization matters

    NM: The stakes go up for automatic data import
    ... There are gambles you are willing to take when heading for
    a web page that are inappropriate for importing
    mission-critical data which may not be used for some time. . .
    ... So starting with an existing algorithm w/o much inclination
    to change it makes me nervous

    <masinter> quiet error recovery in popular browsers is more
    harmful than vendor prefix, but we have this with MIME type
    sniffing too, which is a kind of quiet fixup

    <masinter> sniffing application/xhtml+xml => text/html is an
    automatic fixup

    NM: The pervasiveness of consistent error recovery will change
    community expectations

    RB: For me user-facing software is the key case
    ... But browser deployment will leak, no matter what

    <Zakim> jrees, you wanted to comment on Noah's idea

    TBL: RDF allows XML buried in RDF, it would be good to allow
    XML ER in there [?]
    ... Feeds with XML in can cause real problems -- RSS readers
    must be super-tolerant -- but we keep seeing e.g. DOCTYPEs in
    tweets??? TBL to correct/fill in please

    JAR: So you are heading for tolerance

    RB: Not tolerance, they are still errors, with well-defined
    recovery strategies
    ... The HTML situation is horrible not because of tolerance,
    but because the recovery rules are so complicated because the
    recovery heritage is so complex

    JAR: This will promote a race to the bottom

    RB: Is that a problem, and if so why?

    JAR: There will be no selective pressure
    ... Drift in the correction landscape will eventually lead to
    meaning change

    LM: Sniffing itself has promoted this by the sniffing of
    application/xhtml+xml => text/html
    ... If the popular receivers are strict, then producers will
    check first

    RB: Indeed, and sending the same doc to different browsers with
    different media types makes it worse

    LM: The right place to put this is in Apache and IIS, so the
    data that goes out is fixed

    TBL: And sends a message to root!
    ... Whenever you have a string with two different potential
    readings, you have a security hole

    <jrees> correction is fine but *silent* (i.e. painless)
    correction is a big security risk

    TBL: Simple security attack example for different parsers doing
    different things: Tim puts up a page which he knows Larry's
    browser and Ashok's browser will see differently, asks Larry to
    OK it to Ashok, and then Ashok transfers money to Tim, as he
    sees a different message.

    JT: We are committed to non-silent recovery

    RB: Exactly what that means is up for discussion and
    implementation choice

    HST: It's precisely those honest additions to your assurances
    that make us worried . . .

    NM: Isn't this going to make the sniffing of text/plain as
    application/xml have dire consequences?

    RB: That isn't in scope for the XML ER CG in my opinion,
    because what causes the UA to treat something as XML is prior
    ... The sniffing stuff is someone else's problem

    LM: The sniffing document was originally in the HTML WG
    ... It was moved to the IETF Web Security group
    ... Where some members raised doubts
    ... I'm not involved in the document
    ... It expired at the IETF
    ... The WebApps packaging draft makes normative reference to
    the expired draft
    ... The HTML5 draft has a normative reference to the expired
    ... One of the issues raised against the document was to never
    sniff to PDF, the original editor declined to make any change
    ... No examples have been forthcoming

    RB: The opposite case does arise, that is, correctly labelled
    application/pdf docs being sniffed as something else,
    particularly short ones

    LM: My suggestion wrt sniffing was that any document whose
    media type was determined by sniffing to be different that its
    published type, then it should get a different/unique origin
    ... We have an abandoned document that a) is normatively
    referenced; b) creates a problem wrt XML and error recovery; c)
    contradicts the Authoritative Metadata finding
    ... We should do something, particularly about the XML case

    JAR: If the XML ER CG doesn't say anything about sniffing, the
    TAG will have to. . .

    NM: Sniffing XML as non-XML is clearly not relevant to the XML
    ER CG, but they can say "This algorithm is not robust /
    appropriate / safe when applied to non-XML sniffed as XML,
    don't do that"

    NM: Please reread authoritative metadata since it clearly talks
    about security holes

    NM: People know the arguments against sniffing, they just think
    *their* considerations are more important

    [scribe notes that discussion continued past the end of
    scheduled meeting closure]

    <timbl> Of course the semicolon-adding Javascript behaviour of
    js parsers is a possible security hole, bug etc too

    RB: I'm really concerned that the sniffing spec is dead

    LM: I tried to get that actioned w/o success

    <jrees> yes, applying the pressure early in the development
    chain is best, but if a problem gets past all intermediaries,
    then the final consumer needs to suffer a little, so that there
    is some selective pressure

    <darobin> ACTION: Robin to try to find who is in charge of the
    current browser content sniffing clustermess, and see if there
    is a way of moving out of the quagmire - due 2012-05-01
    [recorded in

      [63] http://www.w3.org/2001/tag/2012/04/03-minutes.html#action03

    <trackbot> Created ACTION-686 - try to find who is in charge of
    the current browser content sniffing clustermess, and see if
    there is a way of moving out of the quagmire [on Robin Berjon -
    due 2012-05-01].

    <darobin> mmm, so long as automatic semicolon insertion is
    well-defined (and it is) I think it's security-safe

    <darobin> whether it's good programming style is another issue,
    of course

    <jrees> no.

    <jrees> speciation in xml would be bad

    <scribe> ACTION: Noah to look for opportunities to discuss
    putting forward something to the AB about the Process and the
    failed reference from RECs to expired RFCs as a side-effect of
    scope creep etc. [recorded in

      [64] http://www.w3.org/2001/tag/2012/04/03-minutes.html#action04

    <trackbot> Created ACTION-687 - Look for opportunities to
    discuss putting forward something to the AB about the Process
    and the failed reference from RECs to expired RFCs as a
    side-effect of scope creep etc. [on Noah Mendelsohn - due

    ACTION-687 due 2012-04-04

    <trackbot> ACTION-687 Look for opportunities to discuss putting
    forward something to the AB about the Process and the failed
    reference from RECs to expired RFCs as a side-effect of scope
    creep etc. due date now 2012-04-04

    <darobin> Jim Fuller has done some excellent work on generation
    of XML language validators based on XSLT/XQuery genetic
    algorithms, so I think speciation in XML may not be so bad ;-)

Summary of Action Items

    [NEW] ACTION: Noah to look for opportunities to discuss putting
    forward something to the AB about the Process and the failed
    reference from RECs to expired RFCs as a side-effect of scope
    creep etc. [recorded in
    [NEW] ACTION: Robin to create a product page proposing the Task
    Force on Web Security/Privileges/Trust/etc. - Due 2012-04-17
    [recorded in
    [NEW] ACTION: Robin to try to find who is in charge of the
    current browser content sniffing clustermess, and see if there
    is a way of moving out of the quagmire - due 2012-05-01
    [recorded in
    [NEW] ACTION: Robin to update Privacy by Design in APIs
    [recorded in

      [65] http://www.w3.org/2001/tag/2012/04/03-minutes.html#action04
      [66] http://www.w3.org/2001/tag/2012/04/03-minutes.html#action02
      [67] http://www.w3.org/2001/tag/2012/04/03-minutes.html#action03
      [68] http://www.w3.org/2001/tag/2012/04/03-minutes.html#action01

     Minutes formatted by David Booth's [69]scribe.perl version
     1.135 ([70]CVS log)
     $Date: 2012/04/17 10:35:09 $

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

============4 April 2012 =============


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

                                - DRAFT -

               W3C TAG F2F 4 April 2012 (Sophia Antipolis)

09 Apr 2012


           Noah_Mendelsohn, Henry_Thompson, Jeni_Tennison,
           Ashok_Malhotra, Tim_Berners-Lee, Jonathan_Rees,
           Robin_Berjon, Larry_Masinter, Yves_Lafon,


           Henry, Noah

           Noah Mendelsohn


      * [2]Topics
          1. [3]httpRange-14 (continued)
          2. [4]Fragment Identifiers and Mime Types
          3. [5]Administrative - f2f dates
          4. [6]HTTP Range-14
          5. [7]TAG Priorities
          6. [8]PhiloWeb
      * [9]Summary of Action Items

    <noah> scribenick: noah

    <scribe> scribe: Noah Mendelsohn

httpRange-14 (continued)

    JAR: We're continuing to follow my 7 section plan. Trying to
    project consequences and criteria, interleaved.

    Shows whiteboard matrix of situations across top, solution
    categories down left, and consequences in middle

    JAR: Talking about receiver, I.e. what Dave Orchard called
    consumer -- someone trying to understand a URI, in context.
    ... Three parties, sender sends a message to receiver within
    which message is a URI. That URI is served by the linkee.

    HT: There are people who will buy in to what we propose (for
    httpRange 14), people who bought into what we proposed 5 years,
    ago, those who don't buy in

    TBL: Well, out there are people buying into a variety of means
    of doing this

    <masinter> I don't understand this deconstruction of having
    "bought in", since I don't see any records of transactions,
    what it is they "bought into", who they bought it from, etc...
    I can understand there are different constituents with
    different opinions about what they do

    TBL: scribe missed some stuff...

    JAR: Want to restrict discussion to default rule -- i.e., no
    special context in document around URI.
    ... mostly we're filling in the white board....

    LM: I'm confused.

    <masinter> Whether people will buy into a theory depends on
    whether that theory is coherent to them and works for their use
    case, among other things

    <masinter> Some reference to "OGP"

    <HT> OGP is a label for the use of hashless URIs for

    <masinter> [10]http://ogp.me/

      [10] http://ogp.me/

    TBL: Roy says the server is an authority
    ... scribe struggling to keep up...


      [11] http://www.w3.org/TR/webarch/#pr-uri-collision

    <ht> [Chris Lilley joins the meeting]

    <masinter> Theory: take "behavior when used in a@href" as the
    definition of what a URI "means", derive all the other meanings
    from that. img@src uses are similar but imply transclusion, and
    xmlns. RDF use in A R B etc is then described in terms of the
    a@href meaning.

    <jrees> See also JARs emacs buffer:

      [12] http://lists.w3.org/Archives/Public/www-archive/2012Apr/0018.html

    <jrees> scribenick: jrees

Fragment Identifiers and Mime Types

    reviewing draft product plan


      [13] http://www.w3.org/2001/tag/products/fragids-2012-01-05.html

    NM: Look at whole space of fragids and mime types. Immediately,
    concerns about 3023bis, about generic interpretation of fragids
    ... one problem was that rdf+xml was operating in a manner
    differing from rule proposed in 3023bis
    ... we said, please abandon the generic rule
    ... response was, the rule is important, we want to keep it
    ... TAG said, OK, call out rdf+xml as a special case.


      [14] http://lists.w3.org/Archives/Public/www-tag/2012Mar/0178.html

    HT: action-675 was to prepare for this discussion. maybe no one
    saw it


    <trackbot> ACTION-675 -- Henry Thompson to frame discussion of
    semantics of fragids and rfc 3023bis -- due 2012-03-27 --


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

    HT: Jeni, a year ago, did this prep. This has to do with advice
    for RDFa Core
    ... we've done half of one part of her advice, we gave advice
    to RDFa Core, they took it.
    ... we never addressed the semantic conflict issue re RDFa
    deployment, you retrieve HTML
    ... Here are more detailed aims for now: Let's decide which
    goals to tackle today
    ... 1. Should advice in AWWW re. conneg and fragids - is it a
    disagreement between media type registrations, or between
    individual documents?
    ... HT and JAR disagreed on this



    HT: 2. What changes, if any would we like to see in 3023bis re
    ... (please ignore the expiration date, that's what we're
    working with)
    ... Are we still happy with our request to the editors?
    ... JAR gave options, TAG said we prefer on balance option 2,
    grandfather rdf+xml as a special case in 3023bis. One case
    ... see reference 7 in ht's email


      [17] http://lists.w3.org/Archives/Public/www-tag/2012Mar/0178.html


      [18] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12

    3. What should we do with Jeni's draft finding?

    lm: The document defining media type regs is in last call in
    app area WG
    ... They added a vacuous SHOULD section about fragids. If we
    want it to be stronger we need to make a comment by LC deadline
    April 13
    ... Maybe Jeni's note provides input

    JT: We're not scoping discussion not just to RDF, but also
    media fragment URIs (consult Yves), we found XML schema id
    complications (consult HT)
    ... would like to make sure these are part of the 3023bis

    <Zakim> jar, you wanted to talk about xhtml+xml

    JR: New information, I think xhtml+xml has the same issue as
    rdf+xml, because of RDFa 1.0

    <masinter> Proposal: create a separate internet draft on
    "Fragment Identifiers for Media Type Registration", and ask
    that the general media type registration document make
    normative reference to it.

    NM: Can we do #2 first?

    CL: (Chris) When I agreed to rdf+xml exception, I thought that
    was the only exception
    ... Jeni section 2.2 points out other contradictions
    ... SVG would need to change in order to allow media fragments



    CL: Because SVG says syntax is either bare name or it's an
    xpointer of some kind
    ... this is true
    ... because we expect to use [etc]

    <darobin> [20]http://simonstl.com/articles/cssFragID.html

      [20] http://simonstl.com/articles/cssFragID.html

    <ht> Jeni's document:

      [21] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12

    CL: There is new CSS xpointer scheme that uses CSS selectors to
    address frags within document

    <darobin> [22]http://www.w3.org/community/cssselfrags/

      [22] http://www.w3.org/community/cssselfrags/

    CL: community group

    YL: Design was to avoid any conflict with SVG for example,

    CL: Fine, but the SVG spec does not allow the new syntax

    YL: SVG with a viewport, identify a region. It's about the
    scope of resolution of the fragment. Also based on application

    HT: We're currently stuck with 3986 which says determined by
    media type

    JAR: No, it only says 'depends on'

    HT: We've always assumed that 'depends on' means 'defined by'
    ... we've assumed fragid is discoverable from media type reg
    (maybe by normative ref)

    <masinter> RFC 3986 " The semantics of a fragment identifier
    are defined by the set of representations that might result
    from a retrieval action on the primary resource. "

    HT: The SVG media type defines fragids, doesn't say anything
    about media fragments

    CL: Surprise that the TAG has read it this way, not sure that
    this is a valuable direction

    <masinter> "The fragment's format and resolution is therefore
    dependent on the media type [RFC2046] of a potentially
    retrieved representation, even though such a retrieval is only
    performed if the URI is dereferenced. If no such representation
    exists, then the semantics of the fragment are considered
    unknown and are effectively unconstrained. Fragment identifier
    semantics are independent of the URI scheme and thus cannot be
    redefined by scheme

    <masinter> specifications."

    <masinter> we could update 3986 if we think that's wrong

    YL: SVG is a good example. image/svg+xml: there's a definition
    in SVG, plus the +xml convention, plus the image/ (media

    CL: multiple inheritance

    <masinter> I think the only resolution for media fragments
    would be to *allow* media tpye registrations to point to it,
    rather than *define* it to apply

    <noah> Best Practice 3: Fragment Identifiers in Media Type

    CL: Therefore carrying on with Jeni's doc. Best practice 3.

    <noah> Media type definitions should avoid 'must' language when
    describing supported fragment identifiers as in practice it is
    likely to be ignored. Instead, they should provide pointers to
    any known fragment structures that might be applied to that
    media type and give warnings of any contradictions between

    YL: Also, there might be Javascript in SVG, and maybe RDFa

    <masinter> media type registrations should explicitly reference
    everything they inherit

    YL: Someone might interpret it in JS, and make something out of

    <timbl_> The TAG ought to encourage generic processing of media
    types to allow conneg to allow any form of migration between
    languages and hence evolution of languages. So generic for
    image/*, for RDFy things, etc. ... so we should not restrict
    the fragment id spec to be only the media type spec. I wonder
    in fact whether we should have a generic ruling that a localid
    with no other puctuation be pointed out that it could be RDFa
    or equivalent for any media type

    CL: SVG shouldn't try to give an exhaustive list
    ... Lots of things need to be excluded, not just rdf+xml

    TBL: I might have jumped to assume that the media type spec is
    the place to look, but generic media type semantics is
    important, for evolution of the web
    ... media fragments are important
    ... in any XML language, if there's a short name without
    punctuation, might be good to look for RDFa; then generic
    warning at top fragid level,
    ... if you have a language that allows barenames in host
    language, you should make sure that you don't use same id in
    rdfa to talk about something different
    ... we should encourage generic

    <masinter> two paths: leave 3986's definition alone, or update
    3986. If you leave 3986 alone, you need to (a) require new
    registrations to follow generic methods, and (b) update all
    existing registrations

    CL: RDF ids are not XML ids
    ... You're saying the two sets should not overlap

    TBL: One bag has punctuation, the other doesn't

    <masinter> I think leaving 3986 alone is workable, and updating
    it is painful.

    TBL: Barenames should never be in the string set you define

    YL: You should avoid syntactical conflicts when you define a
    new feature

    TBL: Stay away from bare names in particular

    <masinter> +xml, +exi, +json, +zip ....

    (JR notes RDF says nothing special about barenames)

    TBL: The simple syntax is sufficiently distinct to suggest
    special treatment in 3023bis

    <masinter> There are some proposals to make scheme-specific
    fragments for streaming protoocols of time-sensitive material,
    e.g., "second 5-10 of rtp:<blah>"

    TBL: Otherwise, it's the local id idea, a huge flexibility
    point, e.g. if you define a python media type, maybe the fragid
    would refer to identifiers defined in the python content

    <masinter> Scripting language inheritance of fragment
    identifies is another generic fragment identifier method

    TBL: You should be able to make global ids using language
    native mode
    ... When you're using barenames be careful since they'll be
    used in this way. Be aware people inserting RDFa, and using
    barenames, and people using barenames in host language must be
    aware that they're sharing a single document-wide namespace,
    and avoid using the same barename for two different things

    <masinter> I think "bare names" needs to fall out of the
    collision avoidance for generic fragment identifier schemes

    HT: Some people not clear on what TBL said... here's an example
    from the wild

    <noah> I heard Tim say: If you're defining a >framework< for
    generating families of fragment IDs, e.g. XPointer, that
    framework should not use barenames, leaving them for
    non-framework use

    <timbl_> Yes

    (JAR has heard the directly contradicting opinion)

    HT: TBL, please see screen. An HTML doc with RDFa, primary
    topic is #jack, with info about that, it's clear #jack is meant
    by author to identify a person. And he's also put div
    id="jack". Is this OK or is it bad?

    TBL: My preferred answer: bad. I want to link to one or the
    other, in the same kind of context, to different kinds of
    things. The 2 things have different properties
    ... I want to be able to use RDF to talk about the DIV element

    <JeniT> Funnily enough, people who create these pages really
    want a link that includes the #jack to jump to the appropriate
    point in the document

    <ChrisL> So best practice, the set of (xml) IDs and the set of
    (RDF) IDS on a given resource should be disjoint

    HT: In the example, the author might say the DIV is about Jack,
    so what's the problem?

    <masinter> Generic fragment identifier mechanisms: +xml, rdf,
    image media fragments, xhtml, javascript

    HT: Stipulate TBL's position, which one ought to be changed?

    <JeniT> So people have to create Javascript to interpret the
    fragment identifier that is being used as the identifier for
    the resource and map that into an anchor within the HTML

    TBL: Jack1 and jack2, separate fragids

    <timbl_> Meanwhile, for barenames, be aware that things like
    RDFA will use barenames and so in other langauges or mixins
    which use barenames, they share a document-wide space

    <masinter> I think what RDFa uses depends on httpRange-14

    NM: I thought I heard CL say, that he has heard the TAG tell
    this story, but if you want to understand fragid semantics,
    then the pertinent spec is the media type registration
    ... Noah wonders if Chris is suggesting loosening this.

    CL: Having looked there then you're not necessarily done.

    NM: Pushing back. IMO, the FYN story is quite important
    ... specs should all point to each other
    ... CL, are you suggesting otherwise?

    LM: The scheme plays NO part

    CL: Yes, there is FYN, 3023bis points to registry, which points
    to registration.

    <darobin> [23]http://www.w3.org/2005/04/xpointer-schemes/

      [23] http://www.w3.org/2005/04/xpointer-schemes/

    CL: rec points to xpointer spec, which points to the xpointer
    scheme registry

    <masinter> I was speaking in reaction to Noah's story in which
    mentioned RFC 2616

    SVG points to the +xml RFC, that gets 3023bis into play

    HT: 3rd thing, it acknowledges it's an image, so it points to
    image/, CL says it doesn't need to point to media fragments

    CL: Need to update image/ spec to point to media fragments
    ... that should do it

    NM: All pertinent specs should have such chains...
    ... Register image/ at generic level, so that semantics can be
    inherited from image/
    ... Principle is that there should be no contradictions among
    the specs
    ... you can't allow the last in chain to make contradictions
    ... We may want to an equivalent thing in +xml, say that if
    you're registering an xml type, there should be no conflict

    <Zakim> masinter, you wanted to propose a solution

    AM: We've been working with a few media types, there are rules
    between them, they're connected
    ... There is this cloud business too, there are tons of media
    types. Cloud providers, machine, network, all media types
    ... Lots of specs need to specify a particular special use of
    fragids. They do so in media types, and sometimes that breaks
    generic processing
    ... All the cloud things use XML, without +xml in the media
    type name
    ... Suppose I want to specify a special semantics for fragids.
    I can make my own media type, but I use XML, but no generic

    <masinter> "Multiview": using multiple media types for the same
    content, to get different interpretations (including fragment

    NM: Generic processing is supposed to not conflict... there's
    nothing in cloud+xml where 3023bis doesn't say you can't
    [scribe missed]

    JR: Are they not using +xml because they don't want generic, or
    because they're not aware, or they would like to, or what?

    AM: Checking

    <Zakim> masinter, you wanted to propose a solution

    LM: I typed what I wanted to say into IRC... there are 2
    solutions, we either keep 3986, or fix it. If we keep it, it
    says meaning comes from media type rec [and consequent FYN
    ... see 3986
    ... Semantics is defined by media type. Therefore it depends

    <noah> [24]http://www.ietf.org/rfc/rfc3986.txt

      [24] http://www.ietf.org/rfc/rfc3986.txt

    LM: That gets pointer to media type rec

    <noah> Quoting from the spec:

    <noah> "The semantics of a fragment identifier are defined by
    the set of

    <noah> representations that might result from a retrieval
    action on the

    <noah> primary resource. The fragment's format and resolution
    is therefore

    <noah> dependent on the media type [RFC2046] of a potentially

    <noah> representation, even though such a retrieval is only
    performed if the

    <noah> URI is dereferenced. If no such representation exists,
    then the

    <noah> semantics of the fragment are considered unknown and are

    <noah> unconstrained. "

    LM: Now we have javascript, xml, media frags, rdfa.

    <ChrisL> the "the set of

    <ChrisL> representations that might result" is not known to the
    person using the fragment, so that is bogus for a start

    LM: Some of the real time folks have suggested fragids whose
    semantics come from the scheme, because there is no retrieval
    ... How do we reconcile these multiple source? One way, is that
    you constrain all future registrations, and update the existing
    ... Media type reg should mention that because you're +xml, it
    should do xml thing, if it says it's an image type then ...,

    YL: You can't say this for future things?
    ... I think it's good if the registration does best effort.

    LM: Can just inherit

    NM: HTML spec could allow for a registry

    LM: My point is either update 3986 to point to a different
    source of generic inheritance other than media type reg, or you
    change media type reg procedure to say that reg should point to
    sources of semantics

    <noah> +1, especially to option #2

    LM: A template could say scripts gets first shot, XML gets a
    shot, +json, +exi, +zip, ...
    ... There's an I-D saying every +xml automatically gets a +exi
    ... We do have a use pattern to consider, the same document
    could be served with different media types because you want
    different processing, maybe because you want different fragid


      [25] http://tools.ietf.org/html/draft-shelby-exi-registration-01

    LM: e.g. /svg vs. /svg+xml, or /xml vs. /rdf+xml, maybe media
    type distinguishes processing in general, including fragid

    YL: One problem statement, we looked at it mainly from document
    point of view. Look at doc in multiple ways.
    ... Different problem is compound documents, i.e. a doc
    containing multiple language, e.g. RDFa


      [26] http://tools.ietf.org/id/draft-shelby-exi-registration-01.html

    YL: The consumer often knows what's intended. E.g. an RDF tool
    that see HTML+RDFa, could present conflict to user. Issue in
    3023bis, you are applying generic processing in particular
    instances , first problem space

    CL: If you start pointing to these, it's not going to work .
    Classic example of compound doc without generic rules, is XSLT,
    frags are not intended to be processed ....

    HT: If you use generic rules for XSLT, they work just fine.
    What doesn't apply is semantics of embedded material, but no
    one ever said that would work
    ... XSLT doesn't require that XSLT style sheets be valid
    ... validity not well-formed
    ... The fragid #foo has a defined meaning, xpointer definition
    says barename refers to first id= element

    TBL: That's a weasel. Consider spirit
    ... The other fragids are there because they're quoted, I
    support what CL says. It's not broken because of one-id

    <Zakim> ht, you wanted to suggest we're being pushed back
    towards application-specific interpretations being allowed and
    to project

      [27] http://examples.tobyinkster.co.uk/hcard

    <JeniT> Yves, what about the YouTube fragid into video example
    you were talking about yesterday?

    <masinter> from

      [28] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04

    <masinter> Since this was published, the defacto practice has
    arisen for using

    <masinter> this suffix convention for other well-known
    structuring syntaxes. In

    <masinter> particular, media types have been registered with
    suffixes such as

    <masinter> "+der", "+fastinfoset" and "+json". This
    specification formalizes

    <masinter> this practice and sets up a registry for structured
    type name

    <masinter> suffixes.

    HT: We haven't done the first half. Where does this leave us
    w.r.t. the +xml section of 3023bis. I'd be happy with: don't
    use the same barename in your RDFa and in your XML, in a +xml
    document. Unless you actually intend for them to have the same

    TBL: Do do it if they're the same

    <masinter> But it doesn't say anything about inheriting a
    common definition of fragment identifier syntax

    <masinter> The primary guideline for whether a structured type
    name suffix

    <masinter> should be registerable is that it be described by a

    <masinter> description, preferably within a document published
    by an established

    <masinter> standards organization, and for which there's a
    reference that can be

    <masinter> used in a References section of an RFC.

    HT: A +xml that uses about="banana" as well as id="apply" is
    OK, even though at the type level, the two are different.
    ... What if the page had had jack1 and jack2, jack1 identifies
    an element, jack2 identifies a person, I'm happy with that
    ... That means there's no grandfathering required then
    ... As Chris said, neither rdf+xml nor RDFa introduce XML
    anchors in any way. Neither has any id= attribute

    <JeniT> There's no *technical* problem; of course the fact that
    barename fragments are used with two separate semantics makes
    it terribly confusing and impractical for people

    HT: So there is no problem with any XML generic processsor as
    every id= that it finds as identifying the element. RDFa never
    introduces id=

    NM: It now essentially says now and only, +xml owns the fragid
    namespace. It could say, we own the ones that are defined, but
    not the ones that aren't
    ... Use syntax disjoint with xpointer if resolution will never
    resolve to an id.

    <masinter> But javascript, image/ might add

    <ht> My proposal for 3023bis wrt fragids: The semantics of
    barename fragment identifiers is as follows: for those
    barenames in a +xml document which are "identifiers of an
    element" as defined in [XPointer Framework], a barename fragid
    identifies the element [XPointer Framework] says is does. The
    semantics of all other barename fragids are unconstrained by
    this specification.

    <JeniT> ChrisL, to capture what you said: document should be
    updated to reference latest version of SVG (ref?) and point to
    different handling in SVG Tiny

    <ChrisL> svg 1.1 first edition

      [29] http://www.w3.org/TR/2003/REC-SVG11-20030114/linking.html

    <ht> I was quoting w/o attribution from 3986

    <ChrisL> svg 1.1 second edition
    www.w3.org/TR/SVG11/linking.html substantially identical

    <ChrisL> svg 1.2 big rewrite plus more sensible barename that
    is not an svg and not an svgview

      [30] http://www.w3.org/TR/SVGTiny12/linking.html

    TBL: We were talking about XML and xpointer. Software that
    processes XML is going to use xpointers, whatever the mime type
    reg says. So we shouldn't be distracted by that.
    ... we could obsess and talk about XML URIs used in the
    pipeline, and so on. But MarkLogic will do xpointer, let's not
    be put off by it

    <masinter> Compound documents are a use case

    <masinter> HTML5 fragement identifier?

    TBL: We're getting into compound documents stuff. Maybe this
    pattern will become dominant. Maybe everything gets thrown
    into, say, HTML

    <masinter> PDF is a compound document format

    TBL: We want to refer to all kinds of things in the same
    namespace, maybe we should worry about this, not conneg, which
    is simpler

    <masinter> Active document fragments more important than
    compound document format?

    AM: To clarify, are you (TBL) saying we should back off on
    generic processing?

    TBL: No. We've just seen a conflict, need to be aware that many
    more may come along

    <masinter> "Last Call" in APPSAWG isn't IETF Last Call, it's
    working group Last Call.

    <Zakim> timbl_, you wanted to say that in fact Norm's code will
    process xpointers whatever specs say, in effect the things
    processed by xml processing pipelines are in away things which

    <Zakim> ChrisL, you wanted to complain about the set of
    possible representations

    CL: Reading through URI spec, it says you have to take the
    union of possible representations, which you have no way of
    knowing. Nobody will ever know about special leap day

    <masinter> "If you say incoherent things, people sometimes
    won't understand you"

    HT: Elsewhere in 3986 it talks about responsible
    administration. You should resolve all or none, and should
    happen consistently

    <timbl> For example, Ashok, people have been talking about
    putting turtle into script tags with a type=text/turtle

    NM: You weren't talking about conneg, but rather about time

    <Zakim> ht, you wanted to propose the above as a resolution to
    what 3023bis should say

    HT: Varying representations. Varying along any dimension
    ... The example I put up leads to the proposal I entered
    ... (displaying, see above)
    ... Semantics is as follows

    CL: While this is good, there is a tendency for people to read
    this and say "this is bogus"
    ... Does it need to call out that other specs can nail it down?

    HT: TBL said don't trespass on the barename space, we ack that

    <Zakim> Masinter, you wanted to push Chris to submit 3023bis

    LM: I want to make sure there's the chain from IETF media type
    reg doc to +xml and to doc on fragids.
    ... Why not resubmit 3023bis as I-D?

    CL: Holdup. Current 3023bis deprecates text/xml because it has
    to be treated as US-ASCII. The reason is because of HTTP and
    email specs

    <masinter> Why not resubmit it now?

    CL: HTTPbis fixes that, email is fixing it

    <scribe> ... New 3023bis will have different authors. Will not
    deprecate text/xml, will say it is same as application/xml...
    that's why the I-D wasn't submitted.

    We're still working out sequence of change w.r.t. email

    LM: Just put a disclaimer, get it out before the 13th
    ... Because media type rec doc needs to reference something,
    deadline soon.

    CL: Acknowledged, I intend to publish I-D new 3023bis, new
    authors, as a placeholder, in next couple of days

    LM: TAG can send note to app area wg, with pointer to Jeni's
    document, saying ...

    NM: Doc status is, I wrote this and it hasn't been reviewed,
    ... We want app area to look at these two docs... does anyone
    object to pointing to unreviewed document?

    LM: I reviewed it

    NM: OK, referencing JT's doc as is OK?

    HT: Not comfortable yet, want to look at it

    LM: Can we put it on phone conference for Tues the 12th

    HT: Don't try to rush this

    <Zakim> Noah, you wanted to talk about Henry's proposal

    HT: I'm happy for it to go out tomorrow, to dated copy with
    what Noah signaled (refer to doc, but doc hasn't had TAG

    LM: No, we agreed to analysis, but not to the doc's

    NM: No objections were heard. But review is not over.

    JT: Could we have an action on someone to write the note?

    LM: I will draft note if JT will review it

    <masinter> You can fix this by *always* using the tools alias
    when you need to contact the chairs or ADs of this or any
    working group: <appsawg-chairs@tools.ietf.org>

    LM: IETF only recognized individual people, not groups.

    NM: It will be signed by someone on behalf of the group
    ... If there's churn there's a problem

    LM: Maybe I will just send a note, saying the TAG has talked
    about it, long discussion. My own note.

    HT: I see no reason not to communicate officially

    NM: Problem is will this happen in the next week...
    ... I would be happy if additionally if we gave advice to those
    writing specific media type regs. Want to tell people how to
    write the specs to make sure everything fits together

    HT: Yes. Maybe go even further and say barename space is a
    valuable space, as TBL says...

    TBL: Advice to document authors

    HT: Where does this advice go?

    TBL: Would like to put it in 3986

    HT: 3986? 3023bis? Media type reg RFC?
    ... 3986

    <masinter> To: apps area working group

    <masinter> Subject: draft-ietf-appsawg-media... review

    <masinter> The W3C Technical Architecture Group has been
    working on issues around conflicting sources of fragment
    identifier semantics in URIs, following the definitions in RFC
    3986 through the media type definition. We believe that those
    defining and registering media types (including ones that
    follow generic rules such as 3023bis ) may need more explicit
    advice than currently contained within draft-ietf-appsawg-.....
    We're working on recording and defining best practice for media
    type definition and fragment identifier semantics;
    --jeni-draft- is a document currently in preparation; our
    intent is to develop this so it can be normatively referenced.

    CL: Generally OK with HT's proposal, need to think it over, but
    spirit seems OK

    <masinter> my goal was just to set the expectation that they
    should look at Jeni's draft as explaining the situation

    HT: Proposal: The TAG should make the proposal I entered to the
    3023bis editors

    <noah> Let's copy it here....

    HT: We had different advice earlier. New info leads to the
    above proposal

    <JeniT> Larry, that looks great to me

    <masinter> "draft-ietf-appsawg-media-type-regs" is the name of
    their document

    HT: Should we now say, consequent on today's discussion and
    JT's doc, there are multiple players, 3023bis to be responsible
    should be very narrow about what is reserved to generic
    processing and leave the rest open
    ... wrt barenames, it only talks about the ones defined in the
    doc, wrt to others, ... xpointer says error, we say no, not an
    error, the semantics is devolved to someone else
    ... we let others with a say in the matter to say it

    NM: Needs update to xpointer?

    HT: No, it's fine for media type reg to short circuit fragid
    semantics in xpointer spec
    ... As far as 3023bis and generic processing there's no there

    CL: You've produced a level of ordering. If xpointer doesn't
    deal with it, then go to next level.

    HT: 3023bis can say this in advance of any update to 3986

    <masinter> Jeni, should we point specifically to Best Practice
    3 "Fragment Identifiers in Media Type Definitions" as something
    we want consensus on?

    HT: I'm trying to help 3023bis get out the door so it helps XML

    LM: The document Chris is preparing, and needs IETF consensus,
    which is community wide. Whatever we say is obviously still
    subject to that
    ... Who would the TAG comment be to?

    HT: The 3023bis editors

    (JAR notes one of them is in the room)

    Discussion of whether it matters how this is said

    CL: I'd like to point out that I started down this road because
    the TAG came to me

    <JeniT> Larry, I think we should say something like that we
    anticipate there being recommendations about requirements on
    media type registrations, such as that in Best Practice 3?

    LM: We got here because some people wanted to assume that if
    they saw +xml, then generic xpointer processing was

    <JeniT> Larry, or no, that we want to specifically discuss what
    to recommend

    <masinter> Jeni, would you like to suggest a rewording?

    <noah> We got here because the then current draft of 3023 bis
    said they MUST treat as generic

    <masinter> When there are multiple communities who disagree on
    best practice, it's hard to get consensus on recommending one
    of their uses over the other.

    <ht> RESOLUTION, The TAG requests the 3023bis editors to adopt
    the following wrt fragids: The semantics of barename fragment
    identifiers is as follows: for those barenames in a +xml
    document which are "identifiers of an element" as defined in
    [XPointer Framework], a barename fragid identifies the element
    [XPointer Framework] says is does. The semantics of all other
    barename fragids are unconstrained by this specification.
    Likewise wrt other fragids using registered XPointer schemes,
    i.e. that XPointer "failure to find" errors are not errors,
    rather a statement of unconstraint.

    <masinter> Can javascript eat up bare names before they get to
    xpointer or xml?

    <masinter> ... and what about


    JT: A bit concerned, this doesn't seem to give scope for
    individual media type registrations to override

    HT: Calling it generic processing means there is no way to
    override it for generic processing

    NM: I had proposed to go further

    JR: Can we propose that separately?

    HT: Consider MUST language in 3986 is separate

    LM: I don't understand the dependency
    ... Does this bear on Polyglot?
    ... If you have something that treats fragids as HTML
    differently than xhtml+xml, could be trouble

    HT: If you access an xhtml, the fact that the xhtml spec says
    something, is in scope. Indirection through xpointer spec
    handles this
    ... 3023 can't say anything about content not served with type

    NM: text/html - HT answered this, when xpointer is used in
    both, [3986 covers this case]
    ... The explanation is tortured

    <darobin> [you can't tell if it's XML or HTML while it's still
    in the box, but the cat is dead all the same]

    HT: Intent of xpointer authors [missed]
    ... Note that I added to make clear that we want something
    parallel for something for (...) xpointers as well. That's in
    the draft resolution

    <noah> RESOLUTION: The TAG requests the 3023bis editors to
    adopt the following wrt fragids: The semantics of barename
    fragment identifiers is as follows: for those barenames in a
    +xml document which are "identifiers of an element" as defined
    in [XPointer Framework], a barename fragid identifies the
    element [XPointer Framework] says is does. The semantics of all
    other barename fragids are unconstrained by this specification.
    Likewise wrt other fragids using registered XPointer schemes,
    i.e. that XPointer "failure to find" errors are not errors,
    rather a statement of unconstraint.

    <noah> Passed without objection.

    <JeniT> Larry, the only thing I'd add is to say what we'd like
    them to do as a consequence

    NM: This rule either must not define interpretations for
    fragids already covered here, or must not provide conflicting
    definitions. Should say new specs *may* do new non-conflicting

    HT: What you must not do is specify a use for strings that will
    appear in documents that they will be determined to id elements
    by xpointers, so they'll fall under this clause; you must not
    set users up to fail

    (Discussion of Noah's proposal, how to word)

    <JeniT> Larry, something like that we would like to discuss how
    best to point media type registration authors to
    recommendations about the definition of fragment identifiers
    and the possibility of their draft pointing out to a separate
    document providing those recommendations?

    HT: TBL's proposal is for 3986. There's nothing wrong at the
    spec level with what rdf+xml says, since the user can always do
    the right thing. They're never obliged to do so
    ... You must not oblige users to hang themselves - that's hard
    to say or place.

    NM: Spirit is: You could write pathological RDFa, and that's

    HT: Maybe we can find an example

    NM: We thought that RDF had made a mistake. The reasoning has
    been so subtle that it's had us talking in circles

    The reasons they didn't make a mistake we may have just

    It appeared that 3023bis that would have applied to rdf+xml.
    Experts thought it was a bug then realized it wasn't. Therefore
    I'm inclined to urge health warnings.

    HT: You mustn't design your XML language so that people can't
    achieve necessary reference using any fragid scheme without
    introducing a semantic conflict with a URI involving a fragid,
    that they can't express in some other way
    ... After the comma isn't needed
    ... , with respect to generic proessing as per 3023bis
    ... You're trying to avoid: I need to use ids to identify
    components. So you must write an id. To id a component, you
    have to put an id on a piece of XML.
    ... to refer to the component you have to write foo#x. But
    generic XML says, if there's an id, then it ids an element. The
    spec shouldn't ever put anyone in that position
    ... that's what we're trying to warn against

    JT: It's OK if it's not typed as an XML id, yes?

    HT: Will the xpointer spec say that string ids an element? If
    so, not good.
    ... The one legit instance , the HTML spec says in English that
    it's an anchor
    ... Three ways xpointer says a string ids an element. schema,
    xml:id, or if you know independently that it ids an element.
    ... That's there so that you don't need the HTML DTD around

    NM: HT is not recommending exactly this text
    ... I hear no objection to this direction
    ... Not as urgent as the previous point.

    <ht> ACTION, Henry to work with Noah to draft a further request
    to the editor from the TAG to include advice along the lines in
    the discussion on media types and fragment identifiers at the
    f2f on 2012-04-04 regarding what a particular +xml media type
    registration should do wrt fragid semantics

    <ht> ACTION: Henry to work with Noah to draft a further request
    to the 3023bis editor from the TAG to include advice along the
    lines in the discussion on media types and fragment identifiers
    at the f2f on 2012-04-04 - Due 2012-05-01 [recorded in

    <trackbot> Created ACTION-688 - work with Noah to draft a
    further request to the 3023bis editor from the TAG to include
    advice along the lines in the discussion on media types and
    fragment identifiers at the f2f on 2012-04-04 [on Henry
    Thompson - due 2012-05-01].

    <noah> ACTION-543?

    <trackbot> ACTION-543 -- Peter Linss to propose addition to
    MIME/Web draft to discuss sem-web use of fragids not grounded
    in media type -- due 2012-03-27 -- OPEN


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

    <ht> ACTION: Henry to work with Noah to draft a further request
    to the 3023bis editor from the TAG to include advice regarding
    what a particular +xml media type registration should do wrt
    fragid semantics along the lines in the discussion on media
    types and fragment identifiers at the f2f on 2012-04-04 - Due
    2012-05-01 [recorded in

    <trackbot> Created ACTION-689 - work with Noah to draft a
    further request to the 3023bis editor from the TAG to include
    advice regarding what a particular +xml media type registration
    should do wrt fragid semantics along the lines in the
    discussion on media types and fragment identifiers at the f2f
    on 2012-04-04 [on Henry Thompson - due 2012-05-01].

    <noah> ACTION: Jeni to sort next steps on Fragment Identifiers
    and Mime Types - Due 2012-04-17 [recorded in

    <trackbot> Created ACTION-690 - sort next steps on Fragment
    Identifiers and Mime Types [on Jeni Tennison - due 2012-04-17].

Administrative - f2f dates

    Mon-Tue-Wed Oct 8-10 (or maybe 7-9)

    Pencil in Oct 7-10

    NM: pencil in Oct 6 too pls
    ... Drift is in England/France direction

    <timbl> The semantics of barename fragment identifiers in a
    mimetype with +xml documentis as follows: When a format mixes
    several languages, (as for example when we mix HTML, RDFa, SVG
    and MathML), then each language allows things to be described
    in terms of document-level bare names. Some of those may be
    defined using the XML ID parameter, ans so will be processable
    using XML pipeline tools. In this case, the barename fragid
    identifies the element [XPointer Framework] says it does. The
    semantics of all other barename fragids semantics of the
    fragment are unconstrained by this specification. .



HTTP Range-14

    <Ashok> scribenick: Ashok

    HT: JAR proposed we should start with the nuclear option
    ... and discuss what the TAG would recommend to various

    Jeni: What's the nuclear option?

    Noah: We need to discuss the change options that people have

    Jeni: We should decide the next steps

    JAR: Consequences of solution categories, criteria for choosing
    a solution category, usecases for elucidating consequences
    ... The advice that would be most difficult for folks to
    swallow is retraction of HTTP Range-14

    <masinter> Some people hate httpRange-14 and some people like
    it. If you withdraw it, you make the people hate it happy and
    the ones who like it unhappy

    <masinter> no?

    JAR: One criterion is interoperability among usecases

    Tim: Usecases are in different shapes

    <masinter> I'm concerned about sender and receiver
    communicating, and I don't care about whether the linkee is

    <masinter> The sender gets to decide which linkee to invoke

    Two Usecases for hashless URIs ... Dublin Core and FOAF

    scribe: See

    <jrees> [37]http://www.w3.org/wiki/HTTPURIUseCases

      [37] http://www.w3.org/wiki/HTTPURIUseCases

    LM: Define constituents more carefully ... senders or receivers
    o people building Dublin Core ontologies

    <masinter> if we make linkees unhappy, i don't care. if some
    recievers are unhappy but could be made happier by senders
    choosing some other linkee to link to, then it's up to the

    <masinter> Melville didn't write any web pages, did he?

    7/mickey-mouse-au-BAC.png dc:creator ??


    HT: Melville is not creator of electronic artifact

    Discussion about Usecase A)

    HT: I see a contradiction

    <masinter> dc:creator has to disambiguate

    JAR clicks on gutenberg URI in the usecase

    <masinter> is [39]http://www.ietf.org/rfc/rfc5013.txt the
    appropriate spec?

      [39] http://www.ietf.org/rfc/rfc5013.txt

    HT: I cannot tell if foaf:maker encodes author or producer

    JAR: Tore Erickson claims every example like this is encumbered

    HT: Better if we choose a home page

    JT: Choose a blog

    <masinter> [40]http://dublincore.org/documents/abstract-model/

      [40] http://dublincore.org/documents/abstract-model/

    <masinter> Is there a mapping to the Dublin Core abstract

    JAR: It's a beautiful idea but no one uses it ... hard to tell
    what the properties of the URI are

    HT: The first usecases should be href=" ..."

    JAR: I want to avoid usecases that do not involve RDF

    Example 2:

    <masinter> You can only avoid use cases that don't use RDF if
    you're willing to scope the results to only apply to RDF

    JAR: We would need to know something about what was on the page

    <jrees> Contrast of 2 examples is not based on what's fetched

    LM: We need to look at how dc:title is defined

    <masinter> i'm looking at

      [41] http://dublincore.org/documents/abstract-model/

    LM: I am looking at Dublin Core abstract model

    HT: Says "we build on RDF"
    ... and to Pat's semantics

    LM: Would this solution make them rewrite the Dublin Core
    abstract model?

    <masinter> Jonathan also wanted to review impact on creative

    JAR: Let's look at Opt-Out

    No negative consequences for sender or receiver

    <masinter> [42]http://wiki.creativecommons.org/CC_REL

      [42] http://wiki.creativecommons.org/CC_REL

    JAR: Opt-In applies only if there is RDFa in retrieved content

    <masinter> gives some markup that CC proposes... will they have
    to change?

    JAR: none of the Opt-In proposals describe what the
    representation is

    HT: We need more qualification with Opt-In

    JAR: Need to say something about the content

    Discussion of improved Example 1

    JAR: Default rule is what is used when there is no other
    information about sender or receiver

    HT: Let us suspend attempt to fill in one more box ...

    How are we going to take this forward to create a
    recommendation and convince people we have followed due

    JT: Need to show what world looks for each example for each

    JAR: We said we would interact with community for 2 weeks

    HT: Need more than another 10 days

    JAR: I would like to ask for some revisions

    HT: We should rewrite in an understandable format ... then
    involve others

    JAR: We should look at second usecase

    LM: I suggest we not spend a lot more time on this ... instead
    form task force of concerned individuals

    NM: This is one of our top priorites ... cannot abandon it

    JT: Larry said "If we cannot drop it let's start a taskforce"

    LM: I don't remember being asked if this was a top-priority
    ... but still should not absorb all of out attention ... we
    have other priorities

    JAR: Task force to make us more effective?

    LM: Yes

    <masinter> RDFa / microdata is a priority

    <masinter> XML / HTML is a priority

    HT: We cannot do this until we have table filled in
    ... getting others involved before that would be confusing
    ... It will take a few person/days to fill out table

    <masinter> [43]http://www.w3.org/2001/tag/products/

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

    <masinter> I'd like to balance work on this vs. other

    JAR: We tried to form a taskforce and it failed ... we did not
    have enough focus ... did not have the table filled in

    Tim: How about a taskforce selected from the TAG

    <masinter> based on the feedback I've gotten from observers of
    the TAG, the priority vs. other topics should be adjusted

    Discussion of taskforce arrangements

    HT: Filling in table is not telcon time.
    ... JAR will fill in table with whatever help he needs

    NM: We may need calls to review filled out table

    <masinter> Noah: JAR had first step, was second?

    <masinter> Noah: First step was to fill out the table
    summarizing the functional characteristics of various solutions

    <jrees> 1. JAR with help fills out the table of categories X
    use case X 3 roles. 2. *In parallel* we tell the community we
    are doing so. Functional chars of different proposals. They
    should look for that. 3. When JAR et al done, we will schedule

    <masinter> Note that is plan

    JAR: Is this sufficient?

    <masinter> this is JAR getting help from other people

    <masinter> Jeni: happy to help

    <masinter> Ashok: do you want to set out a time frame?

    NM: Say 3 weeks?

    <jrees> ACTION jar to Prepare table as described in 2012-04-04
    minutes, for TAG review

    <masinter> /me

      [44] https://www.w3.org/2001/tag/group/track/issues/63

    <trackbot> Created ACTION-691 - Prepare table as described in
    2012-04-04 minutes, for TAG review [on Jonathan Rees - due

    <noah> ACTION-282?

    <trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
    metadata architecture. -- due 2013-04-01 -- OPEN


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

    <masinter> issue-63 has basis of draft: model, serialization,
    vocabularies, linking. Think RDFa/microdata is part of metadata

    <masinter> issue-63?

    <trackbot> ISSUE-63 -- Metadata Architecture for the Web --

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

      [46] http://www.w3.org/2001/tag/group/track/issues/63

    <masinter> product-5?

    Noah takes picture of Whiteboard with filled out matrix


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

    <jrees> ACTION-691?

    <trackbot> ACTION-691 -- Jonathan Rees to prepare table as
    described in 2012-04-04 minutes, for TAG review -- due
    2012-04-24 -- OPEN


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

TAG Priorities

    <masinter> issue-50?

    <trackbot> ISSUE-50 -- URIs, URNs, "location independent"
    naming systems and associated registries for naming on the Web
    -- open

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

      [49] http://www.w3.org/2001/tag/group/track/issues/50

    JT: We said we would spend 10 minutes on Publishing and Linking


      [50] http://www.w3.org/2001/tag/products/index-2012-02-16.html

    - Fragment Identifiers and MiME types

    LM: This is urgent
    ... need credible schedule for completing our work in the next
    few months

    NM: Jeni will update product page. Add Larry.

    HT: I can ask to be area reviewer for Ned's draft
    ... or I can recuse myself

    - Publishing and Linking on the Web

    <masinter> on "Publishing and Linking" as a TAG product, we may
    want to push it out of TAG into a CG

    <masinter> we publish a TAG note that suggests another body
    take it up

    <masinter> i'm nervous about the plan for Publishing and

    <timbl> jrees, [51]http://www.w3.org/wiki/HTTPURIUseCaseMatrix

      [51] http://www.w3.org/wiki/HTTPURIUseCaseMatrix

    <masinter> there might be some discussion of scope of CG

    <masinter> initial draft asks feedback to TAG

    - URI Documentation Discovery

    JAR: Create an option for removing this work from the TAG

    <jrees> See also JARs emacs buffer:

      [52] http://lists.w3.org/Archives/Public/www-archive/2012Apr/0018.html

    HT: Let's postpone that discussion

    Noah updates table online

    - MIME Architecture for the Web

    NM: Move this to a lower priority

    - Privacy by Design

    NM: Robin to draft product page

    - HTML/XML Unification

    <masinter> [53]http://c2.com/cgi/wiki?AlanKayQuotes: A new
    point of view is worth 80 IQ points

      [53] http://c2.com/cgi/wiki?AlanKayQuotes:

    NM: Norm to visit TAG in June

    - Web Apps Storage

    NM: Robin to draft product page

    - HTML Data

    JT: Remove this

    NM: I owe you a closing note

    - XML/HTML Unification

    RB: Shall we shut down the taskforce?
    ... no action lately

    NM: We still have outstanding issues for the TAG

    <masinter> should turn task force report into REC?

    NM: should we look at the issues. Tim said assign shepherd's
    for the issues.

    JAR: I would like 10 minutes on this at the October f2f

    <noah> ACTION: Noah to consider JAR's april request to discuss,
    for 10 mins, issues list at oct f2f - Due 2012-09-10 [recorded
    in [54]http://www.w3.org/2001/tag/2012/04/04-minutes#action04]

    <trackbot> Created ACTION-692 - consider JAR's april request to
    discuss, for 10 mins, issues list at oct f2f [on Noah
    Mendelsohn - due 2012-09-10].


    LM: Henry, Tim and I are listed as talking for the TAG at
    ... I was going to bring there my thoughts about Languages,
    Implementaions and Versioning

    NM: Say it is your perspective


Summary of Action Items

    [NEW] ACTION: Henry to work with Noah to draft a further
    request to the 3023bis editor from the TAG to include advice
    along the lines in the discussion on media types and fragment
    identifiers at the f2f on 2012-04-04 - Due 2012-05-01 [recorded
    in [55]http://www.w3.org/2001/tag/2012/04/04-minutes#action01]
    [NEW] ACTION: Henry to work with Noah to draft a further
    request to the 3023bis editor from the TAG to include advice
    regarding what a particular +xml media type registration should
    do wrt fragid semantics along the lines in the discussion on
    media types and fragment identifiers at the f2f on 2012-04-04 -
    Due 2012-05-01 [recorded in
    [NEW] ACTION: Jeni to sort next steps on Fragment Identifiers
    and Mime Types - Due 2012-04-17 [recorded in
    [NEW] ACTION: Noah to consider JAR's april request to discuss,
    for 10 mins, issues list at oct f2f - Due 2012-09-10 [recorded
    in [58]http://www.w3.org/2001/tag/2012/04/04-minutes#action04]

    [End of minutes]

     Minutes formatted by David Booth's [59]scribe.perl version
     1.133 ([60]CVS log)
     $Date: 2012/04/09 20:15:34 $

      [59] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [60] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 20 April 2012 20:15:04 UTC

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