07:41:17 RRSAgent has joined #tagmem 07:41:17 logging to http://www.w3.org/2012/04/02-tagmem-irc 07:42:54 Ashok has joined #tagmem 07:43:59 timbl has joined #tagmem 07:43:59 robin has joined #tagmem 07:44:17 JeniT has joined #tagmem 07:44:34 Larry has joined #tagmem 07:44:44 jrees has joined #tagmem 07:44:45 ht has joined #tagmem 07:44:57 noah has joined #tagmem 07:45:39 timbl has changed the topic to: INRIA F2F http://www.w3.org/2001/tag/2014/04/02-agenda 07:46:02 trackbot, start telcon 07:46:04 RRSAgent, make logs public 07:46:06 Zakim, this will be TAG 07:46:06 I do not see a conference matching that name scheduled within the next hour, trackbot 07:46:07 Meeting: Technical Architecture Group Teleconference 07:46:07 Date: 02 April 2012 07:46:08 timbl has changed the topic to: INRIA F2F http://www.w3.org/2001/tag/2012/04/02-agenda 07:46:33 agenda: http://www.w3.org/2001/tag/2012/04/02-agenda 07:46:34 http://www.w3.org/2001/tag/2012/04/02-agenda 07:46:55 topic: convene 07:47:05 Noah: agenda review 07:47:25 noah: couple of logistical announcements 07:47:39 DanA will be joining us after lunch 07:47:46 scribe: Larry 07:47:50 scribenic: Larry 07:48:20 noah: (reviewing agenda, visitor schedules) 07:55:47 topic: discussion of TAG priorities and review 07:58:52 zakim, who's here? 07:58:52 sorry, Larry, I don't know what conference this is 07:58:54 On IRC I see noah, ht, jrees, Larry, JeniT, robin, timbl, Ashok, RRSAgent, Zakim, plinss, trackbot, Yves 07:59:04 zakim, this is tagmem 07:59:04 sorry, Larry, I do not see a conference named 'tagmem' in progress or scheduled at this time 07:59:30 topic: http://www.w3.org/2001/tag/2012/04/02-agenda#httpRange14 08:00:39 chair: henry 08:01:04 ht: I'll have a go at chairing, see how that goes 08:01:44 ht: 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 08:02:00 ht: my inclination is to not try to get to the resolution right away 08:03:05 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 08:03:36 jar: roughly 5 parts (maybe 6) 08:03:57 jar: part 1: use cases, of which there are 2-3 08:04:03 jar: part 2: two architectures 08:04:12 jar: part 3: categorization of approaches 08:04:32 jar: part 4: visualizing the two roads to go down.... "what would it be like to go in that direction" 08:04:47 part 5: criteria for making decision 08:05:00 part 6: actually making a decision 08:06:43 topic: part 1, use cases 08:07:26 jar: RDF spec from 1997, section 5, Examples 08:07:39 http:/ww.w3.org/TR/WD-rdf-syntax-971002/ 08:07:57 "RDF is a foundation for processing metadadta" 08:09:13 jar: 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 08:09:36 jar: RDF was motivated by PICS whichc was about rating, before powder 08:10:38 ht: (want a sense of how jonathan is using the terminology) 08:10:59 jar: this is the way i see this use case, as formulated, which i translated into a form that makes sense now 08:11:15 jar: "If I do a get, I will get something which has the properties) 08:11:27 jar: second use case: 08:12:05 s/ww.w3/www.w3/ 08:12:06 http://www.w3.org/TR/WD-rdf-syntax-971002/ 08:12:14 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) 08:12:35 q+ to ask about assertions about resources vs. assertions about representations 08:12:43 jar points to 08:12:44 John Smith john@smith.com +1 (555) 123-4567 08:13:40 jar: the RDF:resource id="John_Smith" in the second use, is really about the person 08:14:05 jar: "URI-based structured data" 08:15:01 jar: expand on this: netflix use case, we have actors, films, separate files in some format, in each entity, there might be some application 08:15:29 jar: 3rd case is one i will talk about an demand, the use of a URL from Amazon to talk about a book 08:16:09 ht: press on ... 08:17:02 jar: I've been trying not to make this RDF specific 08:17:29 jar: About "two architectures": where we are now, for whatever we are, people are wanting to use hashless URIs for both use cases 08:17:53 jar: the relationship between the retrieval results 08:19:05 jar: that's my analysis ...? "the other one is description. The content you get back is different ..." 08:19:38 jar: I'm saying a fact about the two ways these fragments are meant to be used 08:20:23 jar: 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"... 08:20:39 jar: Tim's vision and Roy's vision are different 08:21:18 ht: please be more specific 08:21:45 jar: Roy's latest formulation is "the representation is a record of the state of the resource" 08:21:56 definition in httpBis: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-5 08:22:20 noah: if a "hashless http refers to me" ? 08:22:34 jar: in Tim's version, people don't have hashless URIs? 08:22:45 "Relationship between the representation and the resource is arbitrary and application-dependent" Roy Fielding, as channelled by Jonathan Rees 08:23:16 jar: "If we need to" 08:24:10 jar: i think it might be useful to go over the three definitions of the word 'representation' 08:24:32 "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" 08:24:56 [Above quote from JAR, I think] 08:26:48 larry: *munch* (eating another spoon) 08:28:23 Larry: I think "alleged" is a problem 08:28:45 jar: I've found 15-20 definitions of 'representation', 3 of which are interesting 08:29:10 rep: TBL, 2616? email, the word representation, comes from content negotiation, 08:30:09 "Encoding-format-desensitized methods and means for interchanging electronic document appearances." Patent no., 5,210,824, 1993 May 11 (filed Mar., 1989). 08:31:57 ((JAR reviews matrix on board) 08:32:13 Rep #2: REST, by Roy fielding, in thesis, 3 publications, and in HTTPbis 08:32:54 the type of indentified resource is unconstrainted 08:33:59 jar: 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 08:34:53 jar: "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 08:35:48 q? 08:36:38 q+ to note that I think representation vs. resource is irrlevant 08:36:50 + 08:36:57 Q+ 08:37:14 Jeni put link to 'representation' from HTTP spec 08:38:14 jar: Yves is correct that Roy is working to correct the terminology to be consistent with Rep #2 08:38:56 Definition in HTTPbis: http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-19#section-4 08:39:32 "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)." 08:39:53 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 08:40:37 ack noah 08:40:37 noah, you wanted to ask about assertions about resources vs. assertions about representations 08:41:32 q? 08:42:08 noah: let's say the triple says "was created on" 08:42:30 and it's my thesis, does the assertion apply to the representation or the resource 08:42:56 jar: my theory of resources in sense 1 08:43:13 jar: if you say "if you do a get, you'll come up with something that satisfies the metadata" 08:43:18 q+ 08:43:37 jar: it is my belief that there is an operational behavior 08:43:48 jar: the operational behavior is predictive 08:43:54 ack larry 08:43:54 Larry, you wanted to note that I think representation vs. resource is irrlevant 08:44:37 LM: 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. 08:44:53 q+ to say that JAR's way of defining 'content of' is very good 08:44:54 JAR: Right, we just need to talk about the relationship between the two. 08:45:11 LM: No, we don't want to use the words at all, therefore there's no issue of the relationship. 08:45:45 LM: 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. 08:46:08 JAR: Everything I'm talking about is empirical. I'm talking about these two framings, and related them to the use cases. 08:46:17 LM: I don't think the use cases are different. 08:46:52 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. 08:46:57 LM: No you don't. 08:46:59 TBL: Why not. 08:47:27 LM: 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. 08:47:40 LM: We communicate because we use the same language, not the same dictionary. 08:48:31 LM: 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. 08:48:39 "This book I read, it's called 'Moby Dick', it was written by Hermann Melville, it has a green cover" LM 08:48:50 LM: Then we can reference things like Wikipedia we kind of understand how to share and retrieve. 08:49:22 LM: 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. 08:49:46 LM: 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. 08:50:07 LM: Maybe the triples weren't good enough, in not allowing us to distinguish things we care about. 08:50:29 JAR: In 1998, it was very clear in the RDF draft (some mumbling in the room as to whether everyone agrees) 08:51:02 q+ 08:51:16 LM: 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. 08:51:45 q- 08:51:46 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. 08:51:53 we can't retrofit the definition of what a URI means in order to fix this possible ambiguity in RDF. 08:52:10 HT: It's unclear whether the example in the 1998 draft is about Moby Dick or the Web page about MD 08:52:56 LM: Even if you think RDF has got metadata...the library of congress has Abraham Lincoln's glasses, the glasses themselves, in the catalog. 08:53:07 JAR: The description is in the catalog. 08:53:21 LM: Right, but the catalog entry is for the actual glasses. 08:53:59 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 08:54:32 jar: one example is "automatic mashups", you do a query of documents... and you produce something that has one paragraph from each document 08:54:54 jar: second example: text mining, what do you point your database on? 08:55:13 ht: i think you're right, they wanted (Guha and Tim Bray) to do 08:55:34 s/to do/to give web docs metadata/ 08:55:58 ack timbl 08:55:58 timbl, you wanted to say that JAR's way of defining 'content of' is very good and to 08:56:26 q+ timbl to say that JAR's way of defining 'content of' is very good and to 08:56:35 tim: You said RDF had an ambiguity; there is no ambiguity, the triples aren't ambiguous 08:56:54 s/You said/You (LM) said/ 08:57:15 tim: RDF constrained the ways in which .... 08:57:45 TimBL: RDF was completely clear: under my view, it's clear what the URIs refer to 08:57:51 TimBL: which is documents 08:58:32 TimBL: This constrained how you could use URIs, but it is not ambiguous 08:59:02 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 08:59:09 compared to what was in REST. 08:59:13 jar: there are applications where you need to know whether the bits are content rather than description 08:59:47 ... for example, showing the first paragraph of all the documents that can be found 09:00:02 ... and it needs to make sure that the paragraphs are content from the documents, not from descriptions of the documents 09:00:26 ht: if I want the train schedule, to display the numbers, you have to pay attention to the response code... 09:00:36 ... if it comes back as 404 then you know you don't want to display those numbers 09:00:45 ... you need to know whether the bits are the document or about the document 09:01:19 jar: you need to know whether the bits are the content 09:01:36 timbl: the concept of a document is crucial 09:01:48 ... it's like the content of a string 09:02:12 jar: It's like quote in LISP 09:02:17 larry: this is a distinction that I think is impossible to make 09:02:30 s/quote/'quote'/ 09:02:56 timbl: the URI of the content of Moby Dick and the URI of a review of Moby Dick are different 09:03:35 larry: can we describe this in terms of communication, asserting things in English, then in markup, then in triples 09:04:23 noah: maybe we are tripping over what may be distinguished and what's worth distinguishing 09:04:34 ... a document rendered with different backgrounds on different ways 09:04:53 ... these are two artefacts, roughly different representations 09:05:17 larry: I'm not happy with "I have a document and I give it a URI" 09:05:26 noah: I minted a URI by leasing a domain name etc etc 09:05:47 larry: I'm not happy about 'minting' and 'owner' 09:05:59 noah: two operations were done, two sets of bits came back 09:06:11 ... there were two artefacts, and we can't say they're the same 09:06:18 ... one had a blue background, one not 09:06:26 ... whether we care about that is something else 09:06:37 ... perhaps you're saying we don't care about that 09:07:51 larry: RDF doesn't let me express things that I want to express 09:08:20 timbl: I think originally said that the difference between description and content was not one we could make 09:09:06 not one we could make reliably 09:10:17 ht: clarification of relationship between resource and representation under Roy's view 09:10:31 jar: it cannot be predicted what the relationship is 09:11:16 jar: there are applications where the content/description relationship is essential for the application to work 09:11:31 ... you need to be able to identify whether something is content or description 09:11:55 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 09:12:13 ht: there are people who are building these applications, because they assume a uniform answer to the question 09:12:23 ... if they own both ends, they can satisfy the uniform definition 09:12:30 so the applications are unreliable. maybe they're reliable enough for the applications to be useful anyway 09:12:33 ... own the server and the client 09:12:40 ... so there's no possibility of disagreement 09:12:43 the web is unreliable -- we get 404 not found all the time, but the web is sitll useful 09:13:06 timbl: the RDF folks have built systems where they own both ends, but they include things outside that space, and that's the problem 09:13:23 i think this really leads into persistence, that we want to be mean the same thing for all time, but it's unreliable 09:13:43 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 09:14:04 larry: we have a system where all URIs are not cool, in 10,000 years they will stop working 09:14:14 jar: we can scope to something within the next 5 minutes 09:14:23 ... so you're right, but we're willing to make bets 09:14:50 larry: there are applications that want to make distinctions reliably, and can't, but that doesn't mean they can't be useful 09:15:02 ... the web is not completely reliable, but it's still useful 09:15:16 ... getting the first paragraph of the review of Moby Dick is still useful 09:15:45 ht: let's move on to 'proposal's 09:15:48 ht: let's spend 15 minutes on the third item of the agenda 09:16:28 jar: supposing that we want to make distinctions, let's look at the proposals 09:17:27 what are the possible sources 09:17:33 s/what/jar: what/ 09:18:27 jar: in this case, let's suppose you can determine one bit of information, "content" vs. "description", where can this come from? 09:18:54 jar: (1) it could be in the specification 09:19:12 ht: that's the state we could have been in, if Dan & Tim could have enforced the hash convention 09:19:31 (2) it could be in the status code, headers, content ... it could be in the response 09:20:02 or the information could come from the exchange in http 09:21:03 jar: (3) 3rd source: "the message", the use of the URI, the document in which the URI occurs 09:21:54 (we're not talking about the merits of these) 09:22:08 information could come from any of these places, or a combination of them 09:23:06 ht: this story is situated in a context where you sent me a message that contains a URI 09:23:40 noah: there are other contexts? 09:24:07 ht: we're trying to reduce the uncertanty of a message 09:24:31 noah: "There are situations where i might just find a URI" ? 09:24:55 noah: there might "I just saw a URI?" 09:25:11 q? 09:30:43 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 .... 09:31:20 jar: ... 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 09:31:39 jar: we could have another answer, "httpRange-14b" 09:32:10 jar: Roy believes HTTPbis can't answer this question 09:32:18 jar: "He cares not to discuss this" 09:34:23 jar: New taxonomy of change proposals 09:34:57 "Fixed mode" proposals: 'the answer comes from source (1)" 09:35:28 proposal httpRange-14Strengthened 09:35:43 AlwaysDescription 09:35:51 these are the two fixed answer ones 09:37:06 "Variable Answer" proposal: 09:38:48 jar: 1. 'no agreement' / 'nuclear' option -- no statement about relationship between resource and representation 09:39:59 ... 2. Mode determined from server response 09:40:25 ... 2a. new header that always answer the question, which has to always be present in order to tell 09:40:36 ... 2b. Mode sometimes implicit 09:40:59 ... 2bi. by default content, header means that it's not content but description (TimBL proposal for Document: header) 09:41:49 ... 2bii. by default description, header/message says it's content 09:42:20 s/by default description/by default not content/ 09:44:05 ... 2c. Mode determined at point of use 09:44:23 ... you can't tell from the HTTP exchange at all 09:44:29 ... only from the use of the URI 09:45:11 ht: these could fall into two categories in the same way as 2b, different defaults 09:46:13 2d. Mode determined from the request (eg MGET, Want-Other) 09:46:53 timbl: I don't see how 2c works 09:47:20 ... how does the server know what to give back? 09:47:59 jar: the application will interpret whatever response the server provides back in the way indicated by the context in which it got the URI 09:48:37 ht: handing chair back to noah 09:49:15 noah: we have some unscheduled time 09:49:20 [My 'want-other' proposal about a request header is here: http://www.ltg.ed.ac.uk/~ht/wantOther.html] 09:49:39 ht: I would like 1-1.5 hours 09:49:54 topic: how do we schedule more time on this? 09:50:34 larry: would like to minimize the amount of time on this subject 09:52:04 The want-other document has a potentially useful input to the role-playing discussion 09:52:07 timbl: this has taken up a huge amount of mailing list... would like to make progress in f2f 09:52:28 jeni: I think we can make some progress at this F2F 09:53:02 ht: I think the "role-playing", the next step wants to be "What life would be like in the major categories" ? 09:53:25 henry put a pointer that has an analysis by cases 09:53:35 I.e. an analysis by cases of what happens wrt server vs. client uptake 09:54:35 noah: we'll spend a significant amount of time on this... jeni made the case... we pay a lot to swap in and out 09:56:06 my criteria: (1) persistence... meaning should persist independent of what happens in DNS 09:56:17 (2) URI equivalence ... how to decide on whether URIs are the same 09:56:40 (3) reading on registries, registered values, vs. using URIs in protocols 09:57:31 (4) play without using 'owner', 'mint',... 09:57:51 (5) read on MIME, ... 09:59:49 larry: A story without talking about owners 09:59:56 ... it should work for all URIs, not just HTTP 10:00:15 ... without a distinction between information resource or non-information resource 10:00:30 ... RDF has to be taken as a context, and there are other languages that might have different answers 10:00:31 (6) doesn't rely on 'resource/representation', 'defining what a resource is or whether two resources are the same', 10:00:50 ... like to talk about persistence, which is part of not talking about HTTP 10:01:01 ... something where there's no timeout 10:01:13 ... something that someone can put in a book 10:01:19 jar: a story in which timeout is not implicit 10:01:25 timbl: I suggest that's out of scope 10:01:32 larry: I'm saying what's important to me 10:01:45 ... it's important that it works in archives 10:02:00 ... I'd like it to talk about equivalence of URIs, but not equivalence of resource 10:02:11 ... we don't have a language for naming resources aside from URIs 10:02:24 ... we can compare code points in URIs 10:02:35 ... but not resources 10:02:50 ... We had some other related findings around URIs and registeries 10:03:09 jar: what's the criterion that comes from registeries? 10:03:23 larry: the discussion about URIs is more appropriate around URNs 10:03:27 ... where there is an owner 10:03:43 ... URNs have a story where there are naming things, and documentation and owners 10:03:51 ... but that's the only naming scheme that has that property 10:04:26 ... no one gets to say what HTTP URIs mean other than the implicit meaning 10:04:39 jar: so the criterion is that it should touch on the relationship to registeries? 10:04:45 larry: touch on the relationship between these things 10:05:08 ... I laid out a story around talking in English, then markup languages, then triples 10:05:43 Whiteboard photos for inclusion in agenda: 10:05:44 http://www.w3.org/2001/tag/2012/04/httpRange14Board2_1000px.jpg 10:05:48 ... whatever proposal we accept should be cast into why we care about this as a way of enhancing communication 10:06:09 Closeup of small print on upper right: http://www.w3.org/2001/tag/2012/04/httpRange14Board2Closeup.jpg 10:06:18 ... with the communication being enhanced, so that it's not just talking about philosophy 10:06:47 ... I'm looking for a use case where adopting a solution helps 10:07:15 ... persistence is the one that's hardest, because no one is talking about it and I think it's important 10:07:32 noah: I have a couple of evaluation criteria too 10:07:40 ... there are constraints and good practices in our findings 10:07:49 ... eg don't use one URI to identify two different things 10:07:57 ... that interactions in HTTP should be self-describing 10:08:21 ... if we have a solution that involves HTTP interactions, we should make sure they are consistent 10:08:38 "should work for all URIs, not just HTTP ones, should work for mailto:, data:, ftp:, file:, ..." 10:08:41 jar: the criteria for the story is different from criteria for the solution 10:09:02 noah: apply the criteria at the appropriate point 10:09:10 ashok: I'm nervous about adding lots of equations 10:09:40 ... work on some criteria and then worry about the others 10:09:57 ht: I want a solution that we think is going to change behaviour 10:10:00 s/in our findings/in Architecture of the WWW and in our findings/ 10:10:17 ... there are two outcomes that are plausible 10:10:35 ... one is that we figure out that the current state of play is OK 10:10:42 ... the other is that we adopt a new position 10:10:55 ... if we're going to do that, we had better have a vision about how we get behaviour to change to go there 10:11:09 ... we can't just say what the Right Answer is and then say we're done 10:11:41 timbl: my criteria is that the specific cases that got us into this discussion should be addressed 10:11:55 ... eg 303s, OGP, Flickr should be addressed specifically 10:12:03 ... add Dublin Core as a use case 10:12:23 ... and an answer where we're confident that if they need to change, we can get them to change 10:12:37 ... it must work for Dublin Core and FOAF and RDFS 10:12:52 ... ie hash-oriented vocabularies must continue to work 10:14:56 noah: at what point is it worth identifying one or two solutions might be promising, based on intuition 10:15:04 ... we can ask about whether those hold up 10:15:17 ... then at the end we can look at the other proposals 10:17:21 Topic: Report on Paris IETF Meeting 10:17:28 http://www.w3.org/2001/tag/2012/04/02-agenda#IETFParis 10:18:09 Yves: about HTTP/2.0 10:18:34 http://www.mnot.net/blog/2012/03/31/whats_next_for_http 10:18:42 ... we had representations about 1. SPDY 10:19:13 http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-4.pdf 10:19:41 ... 2. from Willy Tarreau, whose view came from an intermediary point of view, so included info from Squid 10:19:49 ... 3. Waka from Roy Fielding 10:19:54 ... 4. Microsoft S&M 10:20:08 s/S&M/S+M 10:20:10 s/S&M/S+M/ 10:20:39 ... the goal now is to get more concrete proposals on the mailing list for evaluation before the next IETF meeting in July in Vancouver 10:20:49 pointers are in mnot's blog 10:20:54 ... either one document to use as a basis, or two to be compared, one which will fail 10:21:03 ... most of the proposals are for multiplexing at the application level 10:21:11 noah: SPDY is like that? 10:21:14 yves: yes 10:21:24 ... layer 7 10:21:43 ... the main discussion about SPDY is about the use of TLS or not 10:22:00 ... on the mailing list, though that wasn't so evident in the meeting 10:22:05 noah: right, so not e.g. the Google Maps application, but rather the Application layer of the network stack 10:22:27 ... there was one comment about authentication methods 10:22:50 ... the goal would be to completely cover HTTP/1.1 but be able to do extra things 10:23:00 jar: is there an example of something you would be able to do in the new protocol? 10:23:08 yves: eg a new method of authentication 10:23:25 larry: eg Waka includes examples of a single request naming several targets (MGET) 10:23:33 ... that would be a new feature or an optimisation 10:23:50 ... what I was interested in is that SPDY is slower for some sites 10:24:03 ... it requires some optimisation/prioritisation in the client to be used effectively 10:24:17 ... eg high priority for the first part of the document, low for the rest, so you get image headers quickly 10:24:26 ... it's about performance/reliability/security 10:24:34 ... and latency 10:24:40 ... so the features are oriented around that 10:24:59 ... earlier, I sent out a list of IETF meetings of interest, so I can go through that list 10:25:18 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 http://tools.ietf.org/wg/appsawg/ 10:25:58 ... I talked with Thomas and Mark about IETF/W3C dependencies and how to reduce them 10:26:17 ... normative references in W3C specs to IETF specs in progress 10:28:56 ... Apps Area WG meeting 10:29:09 ... Ned Freed's document on updating MIME registration guidelines 10:29:14 ... new draft just out, soon to be last call 10:29:33 ... if we want anything to change about MIME type registration, we need to get it into this document 10:29:45 yves: we already said something about fragments 10:30:06 larry: yes, but we should make sure that it's saying what we want it to say 10:30:18 noah: what are the timing limits? 10:30:22 larry: I don't know, but soon 10:30:35 yves: I looked at a recent version, and it looked ok 10:30:49 noah: it seems like this is something the TAG should look at 10:30:59 ... does anyone else want to sign up to double check? 10:31:17 ht: I will try to find the time, to see if the mime type to URI conversion is universal and reliable 10:31:33 ... it's IANA that manage the registry 10:31:58 ... you can get something back for some of them but not all of them 10:32:17 larry: I suggest we schedule a phone conference to review this document 10:32:29 noah: I need the URI to the document 10:32:44 http://tools.ietf.org/wg/appsawg/ 10:33:33 http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04 10:33:34 larry: the media type reg document is the one we need to review 10:33:43 ... there is another one we need to talk about which is deprecating X- 10:33:49 timbl: is it good? 10:33:55 ht: yes 10:34:13 ... it does say that using prefixes generally is a mistake, for reasons noah will love 10:34:13 ACTION: Noah to schedule (soon) TAG telcon review of http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04 - Due 2012-04-17 10:34:14 Created ACTION-680 - schedule (soon) TAG telcon review of http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04 [on Noah Mendelsohn - due 2012-04-17]. 10:34:26 larry: it's an interesting document that's worth reading 10:34:34 http://tools.ietf.org/wg/appsawg/draft-ietf-appsawg-xdash/ 10:34:53 ... I like this document, but I think TAG members should read it 10:35:37 ACTION: Henry S to prepare TAG discussion of http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04 - Due 2012-04-17 10:35:37 Created ACTION-681 - S to prepare TAG discussion of http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04 [on Henry Thompson - due 2012-04-17]. 10:35:38 noah: should these be reviewed together? 10:35:47 "Deprecating the X- Prefix and Similar Constructs in Application Protocols" 10:35:54 larry: they are independent, and the X- document may not require TAG discussion, though I recommend reading it 10:36:00 and Similar Constructs 10:36:07 LM: Not convinced we need telcon discussion of x-prefix, but TAG should review. 10:36:08 robin: should this be brought to general attention within W3C? 10:36:16 NM: OK, I'll only schedule x-dash if asked. 10:36:17 ... should it be sent to the Chairs list for broader review? 10:36:21 larry: yes, that would be good 10:36:40 larry: there's another document which was discussed 10:36:45 http://tools.ietf.org/html/draft-nottingham-appsawg-happiana-00 10:36:49 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. 10:36:58 ... being prepared to be accepted by the Apps Area WG 10:37:12 ... talking about the process around getting things into registeries 10:37:24 ... based on the happiana effort 10:37:45 ... that document is even more important for Chairs at W3C 10:37:59 ... that's it for the AppAreaWG meeting 10:38:03 ... on to WebSecWG 10:38:22 ... mainly working on strict transport security & TLS 10:38:32 ... also an issue around the mime sniffing document, which has expired 10:39:08 ... the security problem could be addressed by giving sniff content a different origin 10:39:34 ... if you have overridden the mime type, then you have given it a different origin 10:39:44 ... this would address the cross-origin problems that arise from sniffing 10:39:50 ... and I have not seen counter examples 10:40:03 ... it was discussed and dismissed because "browsers won't do it" 10:40:12 ... but browsers don't do what's being said anyway 10:40:20 ... why not have a different fantasy 10:40:50 ... email clients do sniffing all the time 10:40:57 ... the Web Security Handbook talks about sniffing 10:41:21 ... just like we have URIs in different contexts, does sniffing happen differently in different contexts 10:41:41 ... meant to go to URNbis 10:41:47 ... WG revising URN document 10:42:01 ... the TAG has expressed opinions about URNs, and I wish I had gone 10:42:22 ... we should review their documents 10:42:39 jar: I think Julian has been paying attention to what they're doing 10:43:19 larry: my opinion has changed about them 10:43:32 ... it may have been a design goal to have something persistent 10:43:48 ... in fact it is not about persistent, but about ownership 10:44:00 ... there's no owner of an HTTP URI, but there is one about URNs 10:44:19 ... Technical Plenary on browser security 10:44:58 ... HTTP 1.1 is reaching closure 10:45:23 yves: there's currently discussion about folding back documents together, adding a Part 0 so it's easier to find stuff 10:45:30 ... merging Part 1 & Part 3 10:45:36 ... not sure about Part 0 10:45:44 ... currently Part 4-7 are in IETF last call 10:45:54 ... everything else should be in last call from the last draft 10:46:12 larry: these are core documents, and the TAG should review them 10:46:23 yves: most particularly Part 1 & Part 3, the others are extensions 10:46:31 jar: Part 2 is pretty important 10:46:41 s/Part 1 & Part 3/Part 1 to Part 3/ 10:46:52 yves: wait for next draft for review 10:47:17 noah: we often say we should review things, but we don't get people's attention to review them 10:48:13 ... perhaps an email that points to particular things 10:48:36 jar: I could point to the parts I've been paying attention to 10:49:58 ACTION: Jonathan to suggest to TAG sections of HTTPbis specification that TAG should review - Due 2012-04-17 10:49:58 Created ACTION-682 - suggest to TAG sections of HTTPbis specification that TAG should review [on Jonathan Rees - due 2012-04-17]. 10:50:19 jrees_ has joined #tagmem 10:51:29 yves: Dom should be able to report on RTC web 10:51:29 Note to minutes editor: Please add link http://lists.w3.org/Archives/Public/www-archive/2012Apr/0003.html at end of previous topic (that's the emacs buffer that was projected) 10:51:36 ... it was also about security 10:51:45 larry: security is what makes most protocol design hard 10:51:54 ... because you can't just optimise for performance and reliability 10:52:01 ... you have to design against hostile players 10:52:48 ht: what's HyBi doing? 10:52:53 yves: it's WebSockets 10:52:58 ... not the API, the protocol 10:53:34 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 10:53:47 noah: I had missed these were the two sides of the same coin 10:54:02 larry: I don't know what the status is 10:54:12 ... the TAG should have a review or invite someone to come and talk to us about it 10:54:44 ... where we don't have the impetus to review it ourselves, we should get someone in 10:54:59 DKA has joined #tagmem 10:55:19 ht: this is close to home because it's getting integrated into HTML 10:55:35 ... we have to be sure this isn't going to change the architecture of browsing over the next 5 years 10:55:43 larry: I think we should look for someone to come and present to us 10:55:53 noah: any suggestions about who? 10:56:02 yves: Thomas is watching this 10:56:39 larry: we might ask Thomas to recommend someone 10:57:22 ... there was a BOF, where I gave a presentation, to consider the document format of RFCs 10:57:33 ACTION: Yves to figure out who might be a good choice to present Hybi (and as appropriate WebSocket protocols) to the TAG 10:57:33 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]. 10:57:57 ... the driving use case is documents that need non-ASCII characters 10:58:12 ... to show encoding 10:58:34 ... IETF does allow alternative presentations in PostScript and PDF 10:58:50 ... Martin Durst submitted a document on internationalisation of mailto URIs 10:58:52 timbl has changed the topic to: Rough Code and Running Consensus http://www.w3.org/2001/tag/2012/04/02-agenda 10:58:59 ... where the PDF version has examples that are in Unicode 10:59:25 ... running a pre-processor on the XML so that you can have an HTML version with Unicode, and a text version in ASCII 11:01:42 ... the IRI WG 11:01:58 ... again, planning on last calling IRI documents before next IETF meeting 11:02:14 ht: please could you tell me when the XML Core WG should look at those 11:02:21 larry: there are four documents: 11:02:31 ... guidelines & process for registering schemes 11:03:01 ... takes 3987 which used to be one document, and split out section on comparison and bi-directional IRIs 11:03:25 ... the comparison document needs work, because it's a security document to avoid spoofing 11:03:30 ... it can't be a ladder 11:03:52 ... my take is IRI everywhere is not the right answer 11:04:01 ... that there are some contexts where you will want URIs 11:05:13 Adjourn for lunch 11:05:51 rrsagent, make log public 12:22:07 JeniT has joined #tagmem 12:24:22 jrees has joined #tagmem 12:24:31 Ashok has joined #tagmem 12:24:47 Larry has joined #tagmem 12:26:43 ScribeNick: robin 12:27:19 Topic: Can publication of hyperlinks cause copyright infringment? 12:27:28 s/cause/constitute/ 12:27:33 http://www.guardian.co.uk/world/2012/apr/02/email-web-monitoring-powers-privacy 12:28:57 NM: worth reviewing the goals of this work 12:29:20 http://www.w3.org/2001/tag/products/PublishingLinking-2011-12-27.html 12:29:22 [NM reads from the product page] 12:30:07 JAR: who wrote that, it's really good? 12:30:11 NM: we did it together 12:30:22 ... we can always change these goals, but we should do so consciously 12:30:51 http://www.w3.org/2001/tag/products/PublishingLinking.html 12:31:06 NM: we claimed PR in 2012-06, that seems tight 12:31:08 dated version: http://www.w3.org/2001/tag/products/PublishingLinking-2012-01-08.html 12:31:22 ... DKA, are you avaialble for more work on this? 12:31:31 DKA: not in an official capacity, but I will help 12:31:50 AM: how do we make sure it is valuable to policymakers 12:32:08 NM: I don't know, trying to get us in a mindset where we try to make it useful to them 12:32:19 ... we can try, and if it fails learn from our errors 12:32:29 AM: how about asking them earlier if it helps 12:32:39 NM: not sure we want to debate this now 12:32:56 LM: I think it would be useful after reviewing the draft to look into administrative next steps 12:33:02 ... e.g. forming a CG around this 12:33:32 http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2012-01-04.html 12:33:33 NM: review the draft 12:33:55 ... aiming for FPWD 12:34:22 JT: my aim for this session is to get agreement on publication 12:34:47 ... what I'd really like to do is focus on points that people feel strongly should prevent it from FPWD 12:34:52 ... rather than editorials 12:35:02 q? 12:35:14 ack timbl 12:35:14 timbl, you wanted to say that JAR's way of defining 'content of' is very good and to 12:35:25 JT: editorials should be sent by email 12:35:38 timbl has joined #tagmem 12:35:55 ... is there anything that people want to say fisrt off? 12:36:33 nmendels has joined #tagmem 12:36:38 LM: this is a marvellous piece of hard work, my only concerns are about positioning and how we move forward with this 12:36:41 AM: me too 12:36:55 LM: no matter how much we polish it, we will get feedback and divergent comments 12:37:03 JT: but the only way to get those is to put this out there 12:37:19 LM: yes, but I would like to encourage their participation actively 12:37:28 ... (in SotD) 12:37:42 [JT goes through section by section] 12:37:50 JT: Abstract 12:37:58 TBL: this isn't an abstract at all 12:38:42 JAR: matching with goals, does more than set definitions for terms 12:39:12 ... try to match the abstract with the goals from the product page which were really good 12:39:20 LM: the product page could be the abstract 12:39:26 NM: extract some of it at least 12:39:43 q? 12:39:44 LM: not an academic abstract, treat it like an ad for why people should read it 12:40:13 AM: it mentions issues that were raised to the TAG — were they really raised to the TAG? 12:40:20 LM: I'd get rid of that 12:40:23 JT: OK 12:40:46 ... we'll rephrase that last § 12:41:00 DKA: pull it out, highlight that in introduction 12:41:01 s/get rid of that/get rid of the bit about legal issues/ 12:41:16 NM: can be very picky, but don't want to drag the group down 12:41:41 ... but since we're writing for a community of lawyers we should be ruthless about drawing clear distinctions 12:42:09 ... do people agree that that level of care is required? 12:42:17 I think we should indicate that we need to be ruthless, but not before we publish FPWD 12:42:17 ... concerned that this could be used in court 12:42:17 q? 12:42:50 JAR: there's a tension between explaining words used in our community versus words defined by this document 12:43:04 explain words used in the community, as well as defining specific terms which could be used more precisely 12:43:17 ... if the goal is former, then entries need citations (though probably good as a FPWD) 12:43:44 JAR: different goals: being clear, and explaining usage 12:44:13 NM: users versus user agent, not clear 12:44:33 I think we have to do both 12:44:44 q+ to argue for doing both 12:44:46 JAR: careful definition of UA in document, different from usage in some places 12:44:59 JT: different places that define these things are conflicting 12:45:11 JAR: agree, but hard to resolve to tension 12:45:24 LM: the document may have to do both 12:46:00 ... explain how terms are used in the community, and where there are contradictions come up with a new definition and recommend caution in future 12:46:04 q? 12:46:06 ack larry 12:46:06 Larry, you wanted to argue for doing both 12:46:25 NM: usually in the community UA == browser 12:46:37 ... but here the definition is different because it's anything that accesses web content 12:47:16 JT: 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 12:47:31 NM: be precise where we can be, and if it's inappropriate signal it 12:47:39 ... UA is an example of this 12:48:02 TBL: for the TAG in general, the idea of UA is really important 12:48:15 ... for me, a UA is a piece of software that represents me 12:48:50 ... when you put User-Agent, you're representing someone else 12:49:14 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 12:49:58 LM: the problem is that User-Agent header is used to identify the web client rather than a UA 12:50:20 NM: explain the different uses in technical community, and say which one is used here 12:50:55 LM: in most cases there isn't a problem, but for legal cases it may matter 12:51:04 JT: arguably spiders are acting on behalf of someone 12:51:11 LM: but there's no identifiable user 12:51:21 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. 12:51:34 JT: moving on to Introduction 12:51:35 ^ attemtp to capture the best practuces in a scentence for the abstract 12:51:43 well, or at least for identification of whether there is a single responsible person for whose benefit the agent is operating 12:51:55 TBL: Abstract is very good compared to most abstracts out there 12:51:55 1.0 Introduction: 12:52:42 I suggest chg/The page itself may cause/logic encoded with the page may cause/ 12:53:24 NM: 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 12:53:38 ... hence the use of "logic", which is easier to explain 12:53:56 JAR: the notion of agency is central, because this is legal — who causes something to happen? 12:53:56 Well, it's really that, in the real world, pages don 12:53:58 AM: yes 12:54:02 don't caus things to happen. 12:54:13 ... have you looked at the legal interpretation of agency, there's a whole bunch of stuff there 12:54:36 2nd paragraph. 12:54:37 JAR: not sure it's relevant here, might be useful in writing the document, but not necessary to capture it directly 12:54:49 ... good thing to put on the TODO list, but no need to prevent FPWD 12:54:52 AM: yeah 12:54:53 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) 12:55:06 Reason: proxy servers wind up holding onto things for lots of reasons. 12:55:09 TBL: agency makes my rant stronger about UAs acting on behalf of users 12:55:48 3rd para: 12:55:49 Still other services on the web, such as search engines and archives, make copies of content as a matter of course 12:56:21 JAR: "intents and conditions...." don't use passive — this is not editorial because agency matter 12:56:25 Suggest after "matter of course": in part to facilitate the indexing necessary to their operation, and in part to enable presentation of search results" 12:56:53 Suggest delete: (as it enables the content to be found more easily) 12:56:58 DKA: the problem is that if you load these § with contextual clarification then it starts to get quite heavy 12:57:05 JAR: use your judgement 12:57:26 NM: legal community have an extraordinary capability for this, clarity is important 12:58:52 JT: already talked about tightening up terminology — so we can skip over that section 12:59:35 "For instance, one standard set of terms and conditions includes" -- reference? 12:59:46 NM: "not taking into account this complexity" — is this a bad thing? 12:59:53 JT: yes, this is an example of trouble 13:00:43 ... with "distribute", the problem is transfer of ownership because there is no transfer 13:00:54 NM: would be useful to clarify this below the box 13:01:29 HT: the Guardian has this profile thing where they put footnotes 13:01:44 ... you could use little anchors to highlight or signal problems in the text 13:02:05 ... this is a great way to show where the problems are, to make people realise that standard boilerplate is full of gotchas 13:02:20 NM: might be worth picking the problem apart 13:02:38 JT: would you say that throughout the entire background, it would expand it 13:02:49 HT: I was thinking mostly about the box examples 13:03:23 JAR: might be nice to have a couple sentences after each example to explain what is an example about it 13:03:34 LM: can you use a different style for examples? 13:03:56 RB: you can use class=example 13:04:20 NM: this is fine, we can refine style 13:04:32 JT: used blockquote to indicate them 13:05:46 TBL: when you quote gsip.com, is it possible to use a copy of their T&C since it may not be stable 13:07:21 Propose after box on scraping: "Yet, the automated agents on which the Web depends are incapable of reliably understanding such written licenses." 13:07:44 JAR: you can't even mention aa.com, so you couldn't cite the source properly 13:08:34 NM: § that says "limits placed on use of a website"... suggest that after that, you put [pasted above in IRC] 13:09:00 NM: you don't want to fix this, but NLP is not an option 13:09:09 s/but NLP/NLP/ 13:09:26 NM: explain why deep link § is a problem 13:09:34 JT: similar to previous comment 13:09:48 NM: happy to skip if you feel you've got that for all instances 13:10:53 ... the SHOULD not be misleading part — something about the different between SHOULD and MUST ought to be clarified 13:11:18 JAR: this is legal language 13:11:30 NM: right, which may be different from RFC2119 13:11:46 JAR: should we include reference to 2119 in terminology? 13:12:08 ... I don't think it's implied that everything in the box is bad 13:12:21 NM: it's fine if it's clear that these are just examples of things we need to talk about 13:13:30 ... wonder if scope should move up, to establish expectations? 13:14:30 JT: Publishing section 13:14:42 JT: 3.1 Hosting 13:15:25 NM: §1 too strong, trying to say it's not a proxy 13:15:35 ... but is confusing 13:15:40 TBL: what do you mean by that? 13:15:53 JT: it's not a copy of something that's being hosted somewhere else 13:16:13 ... trying to separate out the case where this is the original content 13:16:26 NM: if we have a photograph, hosted on her website 13:16:46 ... I want to copy it (with permission); now we're both hosting it 13:16:52 ... but with your definition I'm not 13:17:04 JT: here we really want to talk about the original, not the copy 13:17:36 TBL: 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 13:18:17 JAR: delete the notion of "original" 13:18:51 Section 3.1, suggest: 13:19:34 HT: the two cases I am concerned with are those in which jailed infringer is said to "just link" to content 13:19:38 JT: he was embedding it 13:19:44 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./ 13:19:49 Reason: surely it's aware of the bits. 13:19:51 ... but he was not hosting it 13:20:11 HT: "just linking" conjures up the notion of clicking, a user action 13:20:31 ... so we need to be clear that hosting here covers that case 13:21:25 NM: my ISP knows what files I've put there 13:21:29 HT: no they don't 13:21:39 ... "know" is not a helpful word 13:21:56 ... they shouldn't be asked to find out if you have child pornography 13:22:17 s/... they shouldn't be asked to find out if you have child pornography/NM: they shouldn't be asked to find out if you have child pornography/ 13:22:23 HT: they know a whole lot less than that 13:23:31 TBL: 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 13:23:40 JT: has "specific" awareness? 13:23:43 HT: ok 13:23:55 to what extent does provenance help ? 13:24:39 [discussion about Wendy] 13:24:55 NM: we should check the awareness issue with her 13:25:17 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") 13:25:31 ... would like this § to dig deeper into the difference between knowing that data is there and knowing its nature 13:26:00 JT: I understand the comments, will rephrase 13:26:11 LM: does the work on provenance help here? 13:26:33 ... were you to record provenance, could you push responsibility back to originator 13:26:38 JAR: out of scope 13:26:44 Noah notes we're run off the end of the parts he's read :-( 13:26:45 LM: why is it out of scope? 13:26:53 JAR/RB: because the technology is not there 13:27:08 LM: but to what extent *could* this be useful? Ask the provenance group? 13:27:24 JT: maybe this could go into section 4 since it's about tecniques? 13:27:44 "any specific awareness of that data being present, much less of its nature." would do it for me 13:28:00 LM: the TAG has more influence over W3C and its groups than web page hosters 13:28:31 HT: there's a WG 13:29:27 [meta discussion] 13:29:53 JT: would like to come out of f2f with plan forward, not just publishing but also potential CG 13:30:59 HT: would anyone object to FPWD at this stage, assuming Jeni takes comments into account? 13:31:17 LM: so long as the abstract is clearer on next steps I would be fine 13:31:30 my only concern is that the introduction makes it clear that we're open as to next steps 13:31:53 JT: let me try to draft something and when we come back on Wednesday we can figure that out 13:31:55 clearer that 'next steps' are open 13:32:18 NM: so no one likely objects to FPWD, how much do we need a longer session? 13:32:43 [no objection] 13:33:06 NM: anything other than actions? 13:33:16 AM: yes. the idea here is to influence the legal ecosystem. 13:33:23 ... publishing it as a finding will not do that 13:33:30 ... a Rec is not enough either 13:33:39 ... it's not sufficient 13:33:43 JAR: you need publicity 13:33:56 AM: need to involve a broader community 13:34:11 JAR: won't be hard to sell, if the EFF learns about it it will be pushed 13:34:20 HT: we will work to push this in public outlets 13:34:39 NM: take an action long term on getting this on policy radar? 13:35:20 LM: 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 13:35:33 i'm concerned that we establish a next step process which actually engaged in discussing the content 13:35:41 NM: so you're saying that some of the relevant people might not be comfortable with www-tag? 13:35:45 LM/AM: yes 13:36:14 NM: we'll talk on Wednesday about next steps 13:36:39 LM: want some feedback from relevant community, not sure how politically sensitive this is 13:37:11 JT: please email further comments 13:37:27 [break] 13:37:43 NM: there will be a short session on this on Wednesday 13:41:40 masinter has joined #tagmem 13:41:43 http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide.pdf#page=6 13:44:36 ScribeNick: JeniT 14:03:48 noah: welcome to Robin 14:04:37 Topic: Web Applications: Privacy by Design in APIs for Web Applications 14:05:06 noah: Product page is no longer a draft: http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html 14:05:11 q+ to ask robin to put the good parts back in 14:05:34 noah: review of http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis-2012-03-27 14:06:31 robin: the feedback I've got is that the scope should be clarified 14:06:35 ... so I will clarify it here 14:06:48 ... the background is: we started working on Geo API 14:07:18 ... this had privacy impacts 14:07:28 ... in DAP we tried to take into account privacy from day one 14:07:37 ... DAP started to think about how to do privacy in APIs 14:07:46 ... one principle was API minimisation which led to DKA's draft 14:07:53 ... now, that is only used in one API 14:08:00 ... and not used in any other WG 14:08:07 ... because we've moved on to other techniques 14:08:27 ... so API minimisation needs to be set into a broader framework 14:08:34 ... applicable to several groups who are defining APIs 14:08:43 q+ 14:08:47 ack dka 14:08:47 DKA, you wanted to ask robin to put the good parts back in 14:08:53 DKA: that all sounds great 14:09:42 ... *but* I think you've taken out bits that shouldn't have been taken out 14:10:36 http://www.cs.virginia.edu/~evans/cs551/saltzer/ 14:10:41 ... for instance, the original draft referenced Saltzer & Schroeder 14:11:01 jar: in academia, this is the seminal classic on the subject 14:11:08 http://escholarship.org/uc/item/0rp834wf 14:11:38 DKA: I understand why you might not want to bring those things up 14:11:55 ... but I think it's important to do so, to mend the fence between the "privacy nuts" and the "script kiddies" 14:12:15 ... there is really good information in the Dierdre Mulligan document 14:12:21 ... and in the Saltzer document 14:12:33 ... these are architectural principles that could be brought into the modern age 14:12:37 Official but paywalled location of S&S's classic: http://dx.doi/org/10.1109/PROC.1975.9939 14:12:46 ... if the additional techniques that you think could be recommended enhance these 14:12:49 ... then point that out 14:13:07 ... point out that it helps to minimise the data that flows down the line 14:13:19 ... I would like that work, which I think is good, to be brought through 14:13:32 robin: I hear that the digestion process was too aggressive 14:13:45 DKA: you know the latest stuff from DAP 14:13:55 q+ to talk about tradeoffs 14:13:55 ... have the principles been tossed out? 14:14:07 robin: mostly the document from which they come has not been updated in three years 14:14:12 ... no one has read it in two years 14:14:18 DKA: did they need to be updated? 14:14:29 robin: I don't have a problem with the meaning of the principles, but the phrasing is probably off 14:14:40 ... because the discussions have happened in other WGs 14:14:48 ... and whenever the document has been cited, it's been ignored 14:15:00 http://dev.w3.org/2009/dap/privacy-reqs/#privacy-minimization 14:15:09 ... so clearly it's not expressing things in a way that people are able to use it 14:15:23 ... I'm happy to try to revive those principles more actively, but we need to rephrase them 14:15:28 ... and I'm happy to do that 14:15:41 ... I really tried to make this document a how-to manual for people busy writing specs 14:16:03 ... so if I'm writing a spec, what do I need to read to get it right 14:16:08 ... a short, checklist document 14:16:24 ... I could re-organise the document so it serves both ends 14:16:37 ... there's good architectural matter in the documents you cited 14:16:48 ... so I will try to restructure to serve both documents, I think that's doable 14:17:05 ... the fast reading for the spec writers, and then there's the background that can inform further thinking 14:17:18 ack next 14:17:18 DKA: yes, and give the reasons for why the techniques work 14:17:33 ashok: when we started this work, we really wanted to do something in the privacy area 14:17:48 ... DKA found this well-scoped, well-defined area, which he wrote up 14:17:55 ... and we hoped we could close on it quickly 14:18:05 ... what I'm worried about is that the scope has been enlarged 14:18:08 robin: slightly 14:18:22 ashok: the parts that you've added are different 14:18:32 ... they seem to be addressing a different problem with different solutions 14:18:56 ... it looks like two ideas in this space, and I'm not sure whether we shouldn't break them up into two things 14:18:56 q+ 14:19:00 q+ 14:19:06 q- 14:19:07 jar: or there might be more, two is a funny number 14:19:12 q+ to comment on scope 14:19:21 ashok: there's lots of issues in privacy, and we couldn't possibly handle them all 14:19:30 robin: I don't want to boil the privacy ocean 14:19:43 ... this document is scoped to what you can do about privacy inside a User Agent API 14:19:50 ... it's not everything that could possibly do in this area 14:20:09 ... but I think it does scope the problem in a way that is useful and applicable by people who are working in this space 14:20:16 ... and it would be difficult to explain them in isolation 14:20:34 ashok: so these are two directions that a user agent could take to help protect privacy 14:20:42 ack next 14:20:43 nmendels, you wanted to talk about tradeoffs 14:20:44 robin: not the user agent, but the design of the API to be run within the user agent 14:20:54 q+ 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 different parties 14:20:56 noah: this is good work 14:21:02 ... I think it's coherent in its scope 14:21:22 ... I'm worried about it taking a long time, so focusing on the most important thing is a good idea 14:21:25 q+ 14:21:46 ... you were saying that you wanted to do a quick guide for people building these things 14:22:10 ... I think the TAG is at its best when it tries to tell stories that have longevity 14:22:54 ... there are tradeoffs in the designs of the APIs 14:23:22 ... I'd expect to see those tradeoffs set out, for example how testable the API is 14:23:30 ... as it will have a bigger surface area 14:23:35 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 http://tools.ietf.org/html/draft-ietf-geopriv-policy-25 in 25th revision 14:23:52 ... also talk about performance 14:24:00 ... numbers of calls on the API 14:24:11 ... draw out the core things 14:24:17 ... to teach people to think deeply 14:24:27 q+ tim0 to discuss the difference between trusted apps an duntrusted apps 14:24:31 ... handy guides are great as well 14:24:44 ... but I'd skew it more towards longevity 14:25:03 q? 14:25:05 ack next 14:25:06 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 14:25:06 ... different parties 14:25:15 timbl: basically, I think it's a very useful document 14:25:21 ... two separate things that occur to me 14:25:29 ... talking about acceptable use 14:25:41 ... that's what came out of a privacy workshop at MIT 14:26:03 ... about capturing policy 14:26:17 ... if you're a user agent, you don't want to do anything unexpected or damaging 14:26:31 ... if I've decided to share something (eg a calendar entry) 14:26:34 q+ jar to urge disclaimer about sampling of techniques, it's not a comprehensive treatment 14:26:38 ... I select the two people to share it with 14:26:45 ... my app might decide to send them emails 14:27:02 ... it would be more reasonable for it to pop up the email so I can edit it 14:27:11 ... it's different to add the name & address to a mailing list 14:27:29 ... which leads to the idea that sometimes there's an implicit use 14:27:55 ... you haven't captured what you said the data could be used for 14:28:09 robin: looking at data usage is a fundamental question in privacy 14:28:17 ... but it's hard to put that into API design 14:28:29 q+ to say we must be willing to say we don't have good answers on, e.g. policy 14:28:35 ... but you'll get pushback from API designers 14:28:47 ... and you'll get a fight, and it won't give progress 14:28:51 jar: can we learn from that conflict? 14:29:18 timbl: the related thing is between a trusted and an untrusted app 14:29:21 q? 14:30:01 ... web apps have to have total power, so they become trusted apps 14:30:17 ... with an untrusted app, it's difficult to stop them from using the data for something different 14:30:27 ... but then there's a trusted app talking to an untrusted app 14:30:27 note long discussion about whether SPDY's use of SSL offers a "promise of improved privacy" 14:30:41 ... at that point it might be reasonable to have a negotiation about acceptable use 14:30:57 ... because the trusted app gathers the data to do something specific 14:31:11 robin: it would make sense, but we don't want to reinvent P3P 14:31:21 ... DAP started looking at rulesets, a simplified version of P3P 14:31:35 ... so a server could say what it wants to do with the data 14:31:45 ... there's only one person in the privacy community who cares 14:31:50 ... and no one in the browser space 14:31:59 ... no one sees how to make that work in the broader sense 14:32:10 ... the solution we've come up with at the moment is user mediation 14:32:24 ... so web intents allow the initiation of communication between a server you trust and another that you don't 14:32:29 ... or vice versa 14:32:42 ... with the user in the middle saying ok about the transfers 14:32:49 q? 14:33:03 q- tim0 14:33:07 ack next 14:33:08 DKA, you wanted to comment on scope 14:33:18 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 14:33:23 DKA: I want to comment on scope and support Robin 14:33:55 ... 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 14:34:09 ... I struggled to think about what that set should say 14:34:18 ... your revised title and scope for this document really made sense to me 14:34:31 ... how do you apply the 'privacy by design' idea to API design 14:34:41 ... I have been thinking about this for a while, and this brought that back to me 14:34:45 ... so I support that idea 14:34:57 http://www.ietf.org/mail-archive/web/privacydir/current/msg00053.html 14:34:57 ... and I think the scope you've chosen is not boil the privacy ocean 14:35:14 ... it's focusing on the API design, rather than all the potential issues that the TAG might hit on privacy 14:35:23 ack next 14:35:25 robin: yes, and it stops where the IAB's work on privacy starts 14:35:35 ... the IAB works up to the protocol layer 14:35:42 ... and I hope their work will also address data usage 14:36:08 larry: I'm really concerned about the TAG taking this on as a work item 14:36:20 ... not because it's not important, but because we're optimising about a moving set of requirements 14:36:50 ... we had a discussion about SPDY's use of SSL and found we didn't really have a common understanding of what privacy meant 14:37:02 ... we're optimising against a goal that is not clearly understood in the industry 14:37:13 ... the GeoPriv policy expression language has been repeatedly revised 14:37:24 ... the subject is controversial enough and has a lot of different perspectives 14:37:44 ... it seems unlikely that the TAG will converge on a finding that will fit with those 14:37:58 ... especially as the IAB is moving about what it covers 14:38:18 q? 14:38:22 ... we have the area of variability around the tradeoffs 14:38:33 ... and about the definition of privacy and the channels of communication 14:38:47 ... and then there's the boundary between this and other TAG work 14:38:58 ... the boundaries feel very fuzzy to me 14:39:12 robin: you're worried about us broadening the scope? 14:39:31 larry: we have a risk of overlapping and saying something contradictory, or leaving a gap between this work and others' work 14:39:50 ... to shallow to the point it's not actionable, or too deep 14:39:55 yves: what about the risk of saying nothing? 14:40:09 larry: what's the boundary between the TAG and the privacy interest group etc 14:40:21 ... there are other groups who are strongly chartered to work on this 14:40:37 wonders if we are really ready to negotiate a boundary with IAB 14:40:38 ... maybe we could come up with something that's shorter and more generic to encourage further work 14:40:47 robin: we should talk about this in the session with Dom tomorrow 14:40:58 ... I did meet up with Christine who is chairing the privacy interest group 14:41:12 ... to discuss whether this is of interest to them, whether they should be doing it, whether the TAG should be doing it 14:41:20 ... I've also been talking about it with the IAB as well 14:41:29 http://tools.ietf.org/html/draft-iab-privacy-considerations-02 14:41:34 ... the reasonable consensus is that the IAB are working at the protocol level 14:41:46 ... and I have the impression that they are happy with this 14:42:03 noah: isn't there a lot of conceptual stuff that has to be sorted out across these 14:42:14 robin: yes, so we've spoken about terminology 14:42:21 ... which is still a moving target 14:42:33 noah: do they include a threat matrix? 14:42:40 robin: they start with an internet privacy threat model 14:42:52 noah: that seems important to agree on, what the problem space is 14:43:14 robin: yes, so their terminology is too much of a moving target to be reused, so that will need to be revisited at intervals 14:43:36 ... as far as the Privacy IG goes, Christine felt that some joint work, either joint review or a joint TF 14:43:57 ... to look at policy and that we could contribute technological view 14:44:22 larry: I talked to people at the IETF meeting, to the IAB, to Wendy, to Thomas, and they didn't mention any of this 14:44:52 ... for you to have a private discussion, that the others in the IAB and Privacy IG aren't aware of makes me worried 14:45:15 robin: these discussions happened Thursday and Friday 14:45:37 larry: we need to arrange discussions with the IAB in order to collaborate with them 14:46:06 noah: getting colocated with the IAB has proven difficult 14:46:18 ... we couldn't have a TAG meeting at the same time as the IETF meeting 14:46:42 larry: my concern is about overlapping with other groups 14:46:45 ack next 14:46:47 jar, you wanted to urge disclaimer about sampling of techniques, it's not a comprehensive treatment 14:47:23 jar: there's something that feels incomplete about the draft 14:47:28 ... about how the scope is set 14:47:41 ... if you just look at the title it looks like it's about all privacy issues 14:48:09 ... what you've said today about the scope is really important, and should go into the introduction 14:48:25 ... this is really just a sampling of things that have come up through the WG process 14:48:44 timbl: you could have a related work section 14:48:51 jar: there's a lot of interesting stuff in this space 14:49:03 ... you should say that 14:49:11 noah: say why we chose these bits now 14:49:24 ... and what you should watch out for because we haven't covered it here 14:49:43 ... stuff that hasn't been touched: different threat models, different capabilities 14:50:14 jar: give space for the reader to realise that this is a sampling of what we know about right now 14:50:30 ... it might end up being complete, but because it's an active area it's unlikely to be 14:50:44 robin: this is like a BCP more than anything else 14:51:03 noah: it might just be early 14:51:23 ... a year ago people were talking about minimisation 14:51:32 timbl: I like 'patterns in API design' 14:51:47 ... and you could mention an anti-pattern, things that you didn't cover 14:51:57 ... you're not saying they're best, that they could work for some people 14:52:16 robin: the reason I didn't use 'pattern' was that several groups said it would tie it to 'design patterns' 14:52:29 ... which is a little old-fashioned 14:53:51 ... personally 'pattern' would have been something that I would have used, but some people are scared of using that word 14:53:54 ack next 14:53:55 nmendels, you wanted to say we must be willing to say we don't have good answers on, e.g. policy 14:53:56 ... I'm happy to try using it 14:54:48 Alexander et al A Pattern Language 14:54:51 1865 14:55:47 q? 14:55:58 q? 14:55:59 noah: talking about policy, and that we don't have good answers 14:56:14 q+ 14:56:23 ... there's a risk of telling the piece of the story we understand in isolation 14:56:37 ... and perhaps without policy it doesn't matter 14:57:32 ... need to explain which part of the problem these designs will solve 14:57:36 http://www.amazon.com/Pattern-Language-Buildings-Construction-Environmental/dp/0195019199/ref=sr_1_1?s=books&ie=UTF8&qid=1333378641&sr=1-1 14:57:41 ... and what issues it doesn't solve 14:57:53 ... if it can do it without talking about policy, I'm happy 14:58:20 robin: I think that's part of explaining the scoping better 14:58:35 ack next 14:58:39 q? 14:58:41 noah: let's see if we can tell enough of the story with this 15:01:28 noah: we have another session on this tomorrow to review how this went with Dom 15:01:37 ... and we can go over logistics at that point 15:01:57 ... so let's wrap this up for now and come back on it tomorrow 15:03:29 timbl_ has joined #tagmem 15:06:05 Adjourned 15:06:33 rrsagent, draft minutes 15:06:33 I have made the request to generate http://www.w3.org/2012/04/02-tagmem-minutes.html JeniT