IRC log of tagmem on 2012-04-02

Timestamps are in UTC.

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