Draft Minutes of TAG F2F 2-4 April 2012 from Noah Mendelsohn on 2012-04-20 (www-tag@w3.org from April 2012)

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Fri, 20 Apr 2012 16:14:27 -0400
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>
Message-ID: <4F91C3A3.8010107@arcanedomain.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.

Noah

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

============2 April 2012 =============
[1]W3C

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

- DRAFT -

Technical Architecture Group Teleconference

02 Apr 2012

[2]Agenda

[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

Attendees

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

Regrets

Chair
Noah Mendelsohn

Scribe
Larry

Contents

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

Convene

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

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

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
powder

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
properties)
... second use case:

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

[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"
as="bib"?>

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

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

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

<RDF:serialization>

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

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

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

</RDF:assertions>

</RDF:serialization>

<RDF:resource id="John_Smith">

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

<bib:email>john@smith.com</bib:email>

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

</RDF:resource>

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
cases
... 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
jonathan
... "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:
[18]http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-19
#section-4

[18]
http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-19#section-4

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

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
ambiguous

<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
ways
... these are two artefacts, roughly different representations

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

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
definition

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

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
from?
... (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
content
... 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]

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

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

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
URIs
... we can compare code points in URIs
... but not resources
... We had some other related findings around URIs and
registeries

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

larry: the discussion about URIs is more appropriate around
URNs
... 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:

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

[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

[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
behaviour
... there are two outcomes that are plausible
... one is that we figure out that the current state of play is
OK
... 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

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

Yves: about HTTP/2.0

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

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

Yves: we had representations about 1. SPDY

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

[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
not
... on the mailing list, though that wasn't so evident in the
meeting

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

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

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

noah: I need the URI to the document

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

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

<ht>
[27]http://tools.ietf.org/html/draft-ietf-appsawg-media-type-re
gs-04

[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
[28]http://tools.ietf.org/html/draft-ietf-appsawg-media-type-re
gs-04 - Due 2012-04-17 [recorded in
[29]http://www.w3.org/2001/tag/2012/04/02-minutes#action01]

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

<trackbot> Created ACTION-680 - schedule (soon) TAG telcon
review of
[30]http://tools.ietf.org/html/draft-ietf-appsawg-media-type-re
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

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

[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
[32]http://tools.ietf.org/html/draft-ietf-appsawg-media-type-re
gs-04 - Due 2012-04-17 [recorded in
[33]http://www.w3.org/2001/tag/2012/04/02-minutes#action02]

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

<trackbot> Created ACTION-681 - S to prepare TAG discussion of
[34]http://tools.ietf.org/html/draft-ietf-appsawg-media-type-re
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

<Larry>
[35]http://tools.ietf.org/html/draft-nottingham-appsawg-happian
a-00

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

larry: being prepared to be accepted by the Apps Area WG
... talking about the process around getting things into
registeries
... 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
expired
... 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
it"
... 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
gone
... we should review their documents

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

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
URNs
... 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
[37]http://lists.w3.org/Archives/Public/www-archive/2012Apr/000
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
reliability
... 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
HTML
... 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
[38]http://www.w3.org/2001/tag/2012/04/02-minutes#action04]

<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
characters
... to show encoding
... IETF does allow alternative presentations in PostScript and
PDF
... 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?

<ht>
[39]http://www.guardian.co.uk/world/2012/apr/02/email-web-monit
oring-powers-privacy

[39]
http://www.guardian.co.uk/world/2012/apr/02/email-web-monitoring-powers-privacy

noah: worth reviewing the goals of this work

<JeniT>
[40]http://www.w3.org/2001/tag/products/PublishingLinking-2011-
12-27.html

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

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

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

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

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

<JeniT> dated version:
[42]http://www.w3.org/2001/tag/products/PublishingLinking-2012-
01-08.html

[42]
http://www.w3.org/2001/tag/products/PublishingLinking-2012-01-08.html

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

<JeniT>
[43]http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb
-2012-01-04.html

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

noah: review the draft
... aiming for FPWD

JeniT: my aim for this session is to get agreement on
publication
... 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
this

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
actively
... (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
terms
... 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
conflicting

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
consistent

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

timbl: Abstract is very good compared to most abstracts out
there

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

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
footnotes
... 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
IRC]
... 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
instances
... 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
bad

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
content

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

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

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

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
nature

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

<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

[break]

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

<Larry>
[44]http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/D
ynamicMediaXMPPartnerGuide.pdf#page=6

[44]
http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide.pdf#page=6

<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:
[45]http://www.w3.org/2001/tag/products/apiminimization-2012-02
-02.html
... review of
[46]http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis-20
12-03-27

[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
clarified
... 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
framework
... applicable to several groups who are defining APIs

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

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

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

[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

<DKA>
[50]http://dev.w3.org/2009/dap/privacy-reqs/#privacy-minimizati
on

[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
right
... a short, checklist document
... I could re-organise the document so it serves both ends
... there's good architectural matter in the documents you
cited
... 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
use
... you haven't captured what you said the data could be used
for

robin: looking at data usage is a fundamental question in
privacy
... 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
app
... web apps have to have total power, so they become trusted
apps
... 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
specific

robin: it would make sense, but we don't want to reinvent P3P
... DAP started looking at rulesets, a simplified version of
P3P
... 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
mediation
... 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

<Larry>
[52]http://www.ietf.org/mail-archive/web/privacydir/current/msg
00053.html

[52]
http://www.ietf.org/mail-archive/web/privacydir/current/msg00053.html

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
revised
... 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
communication
... and then there's the boundary between this and other TAG
work
... 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'
work
... 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
tomorrow
... 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

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

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

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
meeting

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

<timbl>
[54]http://www.amazon.com/Pattern-Language-Buildings-Constructi
on-Environmental/dp/0195019199/ref=sr_1_1?s=books&ie=UTF8&qid=1
333378641&sr=1-1

[54]
http://www.amazon.com/Pattern-Language-Buildings-Construction-Environmental/dp/0195019199/ref=sr_1_1?s=books&ie=UTF8&qid=1333378641&sr=1-1

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

Adjourned

Summary of Action Items

[NEW] ACTION: Henry S to prepare TAG discussion of
[55]http://tools.ietf.org/html/draft-ietf-appsawg-media-type-re
gs-04 - Due 2012-04-17 [recorded in
[56]http://www.w3.org/2001/tag/2012/04/02-minutes#action02]
[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
[58]http://tools.ietf.org/html/draft-ietf-appsawg-media-type-re
gs-04 - Due 2012-04-17 [recorded in
[59]http://www.w3.org/2001/tag/2012/04/02-minutes#action01]
[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
[60]http://www.w3.org/2001/tag/2012/04/02-minutes#action04]

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

[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

Attendees

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

Regrets
Peter Linss

Chair
Noah Mendelsohn

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

Contents

* [3]Topics
1. [4]Web APIs and security
2. [5]Web Applications: Security and Web Applications
Permissions
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
connector

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

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

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

<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
[13]https://lists.w3.org/Archives/Member/w3c-ac-members/2012Jan
Mar/0057.html

[13]
https://lists.w3.org/Archives/Member/w3c-ac-members/2012JanMar/0057.html

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
messages

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
other

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 -
(missed)]

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

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

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

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

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

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

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

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

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

<masinter>
[24]http://tools.ietf.org/html/draft-ietf-geopriv-dhcp-lbyr-uri
-option-14

[24]
http://tools.ietf.org/html/draft-ietf-geopriv-dhcp-lbyr-uri-option-14

<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

[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

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

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.

<masinter>
[30]http://masinter.blogspot.com/2011/08/internet-privacy-telli
ng-friend-may.html

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

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
level

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
experts

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
landscape

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
clear

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
]

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

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

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

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

<noah> close ACTION-514

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

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

[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

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

[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

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

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

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

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

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

NM: Time to get this over the last hurdles

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

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

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

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

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

[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:
[42]http://www.w3.org/2001/tag/products/clientsidestorage-2012-
03-02.html]

[42]
http://www.w3.org/2001/tag/products/clientsidestorage-2012-03-02.html

<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

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

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

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
media

AM: Right

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

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

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

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
problem

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
help

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

[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

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

[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

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

[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

<masinter>
[49]http://tools.ietf.org/html/draft-ietf-iri-comparison-01
should update 3986

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

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

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

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

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

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

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

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

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

<noah> Project Blue Spruce may be of interest:
[54]http://www-01.ibm.com/software/ebusiness/jstart/bluespruce/

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

<darobin>
[55]http://www.readwriteweb.com/archives/ibm_blue_spruce_first_
look.php

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

<masinter>
[57]http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-0
0

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

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
identities
... One proposal is to use mutually-trusted shared identity
providers, such as Facebook, to reciprocally verify

<dom>
[58]http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-id
p-01

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

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

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

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

Administration

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
[61]http://lists.w3.org/Archives/Public/www-archive/2012Mar/att
-0007/AB_List_of_Concerns-20120306.htm ?

[61]
http://lists.w3.org/Archives/Public/www-archive/2012Mar/att-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
error

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
DB
... 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
apps
... 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
draft
... 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
]

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

[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
2012-04-10].

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
[65]http://www.w3.org/2001/tag/2012/04/03-minutes.html#action04
]
[NEW] ACTION: Robin to create a product page proposing the Task
Force on Web Security/Privileges/Trust/etc. - Due 2012-04-17
[recorded in
[66]http://www.w3.org/2001/tag/2012/04/03-minutes.html#action02
]
[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
[67]http://www.w3.org/2001/tag/2012/04/03-minutes.html#action03
]
[NEW] ACTION: Robin to update Privacy by Design in APIs
[recorded in
[68]http://www.w3.org/2001/tag/2012/04/03-minutes.html#action01
]
__________________________________________________________

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

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

- DRAFT -

W3C TAG F2F 4 April 2012 (Sophia Antipolis)

09 Apr 2012

Attendees

Present
Noah_Mendelsohn, Henry_Thompson, Jeni_Tennison,
Ashok_Malhotra, Tim_Berners-Lee, Jonathan_Rees,
Robin_Berjon, Larry_Masinter, Yves_Lafon,
Chris_Lilley_(for_the_morning)

Regrets
Peter_Linss

Chair
Henry, Noah

Scribe
Noah Mendelsohn

Contents

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

<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

[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/001
8.html

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

<jrees> scribenick: jrees

Fragment Identifiers and Mime Types

reviewing draft product plan

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

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

<ht>
[14]http://lists.w3.org/Archives/Public/www-tag/2012Mar/0178.ht
ml

[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

action-675?

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

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

[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>
[16]http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lil
ley-xml-04.html#frag

[16]
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag

HT: 2. What changes, if any would we like to see in 3023bis re
fragids?
... (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
exception.
... see reference 7 in ht's email

<ht>
[17]http://lists.w3.org/Archives/Public/www-tag/2012Mar/0178.ht
ml

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

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

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

<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

<noah>
[19]http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-
12#inconsistent-semantics-and-processing

[19]
http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12#inconsistent-semantics-and-processing

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

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

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
Definition

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

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
it

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

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
processing

<masinter> "Multiview": using multiple media types for the same
content, to get different interpretations (including fragment
identifier)

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

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

<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
body
... How do we reconcile these multiple source? One way, is that
you constrain all future registrations, and update the existing
ones.
... 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
processing

<darobin>
[25]http://tools.ietf.org/html/draft-shelby-exi-registration-01

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

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

<masinter>
[26]http://tools.ietf.org/id/draft-shelby-exi-registration-01.h
tml

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

<Zakim> ht, you wanted to suggest we're being pushed back
towards application-specific interpretations being allowed and
to project
view-source:[27]http://examples.tobyinkster.co.uk/hcard

[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-re
gs-04

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

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

<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

[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

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

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

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

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

LM: No, we agreed to analysis, but not to the doc's
recommendations

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>
<appsawg-ads@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
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
community

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

<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
[31]http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-
authoring-guide.html

[31]
http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html

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
something+xml

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
stuff

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

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
discovered

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
[32]http://www.w3.org/2001/tag/2012/04/04-minutes#action01]

<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

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

[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
[34]http://www.w3.org/2001/tag/2012/04/04-minutes#action02]

<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
[35]http://www.w3.org/2001/tag/2012/04/04-minutes#action03]

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

<timbl>
[36]http://www.w3.org/wiki/HTTPURIUseCases#Refer_to_a_document_
from_RDFa_within

[36]
http://www.w3.org/wiki/HTTPURIUseCases#Refer_to_a_document_from_RDFa_within

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
constituencies

Jeni: What's the nuclear option?

Noah: We need to discuss the change options that people have
proposed

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
happy

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

<masinter> Melville didn't write any web pages, did he?

<masinter>
[38]http://www.operationteafortwo.com/wp-content/uploads/2011/0
7/mickey-mouse-au-BAC.png dc:creator ??

[38]
http://www.operationteafortwo.com/wp-content/uploads/2011/07/mickey-mouse-au-BAC.png

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

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/

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

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

JT: Need to show what world looks for each example for each
proposal

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
priorities

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

<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

[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
2012-04-11].

<noah> ACTION-282?

<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
metadata architecture. -- due 2013-04-01 -- OPEN

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

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

<masinter> issue-63?

<trackbot> ISSUE-63 -- Metadata Architecture for the Web --
open

<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

<masinter>
[47]http://www.w3.org/2001/tag/group/track/products/5

[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

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

[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

<noah>
[50]http://www.w3.org/2001/tag/products/index-2012-02-16.html

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

<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/001
8.html

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

PhiloWeb

LM: Henry, Tim and I are listed as talking for the TAG at
PhiloWeb
... I was going to bring there my thoughts about Languages,
Implementaions and Versioning

NM: Say it is your perspective

ADJOURNED

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
[56]http://www.w3.org/2001/tag/2012/04/04-minutes#action02]
[NEW] ACTION: Jeni to sort next steps on Fragment Identifiers
and Mime Types - Due 2012-04-17 [recorded in
[57]http://www.w3.org/2001/tag/2012/04/04-minutes#action03]
[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