16:03:38 <RRSAgent> RRSAgent has joined #tagmem
16:03:38 <RRSAgent> logging to http://www.w3.org/2011/11/04-tagmem-irc
16:03:49 <Zakim> Zakim has joined #tagmem
16:03:59 <ht> Meeting: TAG f2f
16:04:11 <ht> ScribeNick: ht
16:04:11 <ht> Scribe: Henry S. Thompson
16:04:20 <ht> Chair: Noah Mendelsohn
16:04:22 <Ashok> Ashok has joined #tagmem
16:05:06 <jar> jar has joined #tagmem
16:05:32 <ht> Agenda: http://lists.w3.org/Archives/Public/www-tag/2011Oct/0119.html
16:05:39 <ht> Topic: SPDY
16:05:54 <ht> Present: TBL, NM, PL, AM, HST
16:06:14 <ht> Guests: Peter St. Andre, Mike Belshe
16:06:54 <ht> Guests+ ABth
16:09:11 <ht> Present+ DKA, LM
16:09:46 <ht> NM: RDFa vs. Microdata will require our attention wrt HTML WG process by mid-January, we will return to this
16:10:14 <ht> AM: Web Storage is headed for Last Call, we may need to feed in here
16:10:17 <DKA> DKA has joined #tagmem
16:10:18 <ht> s/need/want/
16:10:41 <ht> NM: [introduces the TAG to MB]
16:13:53 <ht> zakim, room for 2 for 90 minutes?
16:13:54 <Zakim> ok, ht; conference Team_(tagmem)16:13Z scheduled with code 26632 (CONF2) for 90 minutes until 1743Z
16:14:36 <Zakim> Team_(tagmem)16:13Z has now started
16:15:39 <stpeter_> stpeter_ has joined #tagmem
16:16:29 <stpeter_> Yves, Henry is working to set up the Zakim bridge
16:17:22 <ht> present+ YL
16:17:45 <ht> Yves, what's your google id?
16:19:24 <ht> MB: Was at Google until 2 months ago, worked on the Chrome team, we started SPDY around 2008
16:19:50 <ht> MB: Google focus on performance, so interested in protocol speedup
16:20:13 <ht> MB: Using the existing mechanisms in HTTP was just gnarly
16:20:33 <ht> ... So we started experimenting in the lab with doing something of our own
16:20:52 <ht> ... but based on a lot of prior work in a lot of areas
16:21:27 <ht> MB: SPDY is beginning to spread -- Firefox have started some work
16:21:53 <ht> ... to date we've owned it, published an informal spec., some unit tests
16:22:19 <ht> ... Firefox adoption possibility has pushed us towards standardization
16:22:44 <ht> ... Interop guarantee is necessary before we can move forward
16:23:59 <stpeter_> Roberto Peon
16:24:16 <ht> MB: Roberto Peon is the person at Google who is on point for SPDY now
16:24:58 <ht> ... We looked at taking this to the IETF, and that took me to PStA
16:25:25 <ht> NM: We got in to this also in part because of our contact with Jim Gettys over the buffer bloat issue
16:26:11 <noah> about:net-internals in chrome
16:26:22 <ht> MB: State of play -- Google Chrome now using SPDY for all SSL traffic, see about:net-internals
16:26:34 <ht> ... Firefox is implementing it
16:27:28 <ht> ... Amazon Kindle Fire recently announced that they will be using SPDY
16:27:59 <ht> MB: A number of other less big names involved, implementations in Python and Ruby, etc.
16:28:12 <ht> MB: Main parts of SPDY:
16:28:19 <ht> ... 1) Multiplexing;
16:28:28 <ht> ... 2) Compression;
16:28:38 <ht> ... 3) Prioritization;
16:28:46 <ht> ... 4) [Maybe] Server push
16:29:11 <ht> MB: Goal _is_ performance
16:29:45 <stpeter_> http://www.ietf.org/proceedings/80/slides/httpbis-7.pdf (SPDY slides from IETF  80)
16:29:54 <ht> ... Interaction of HTTP and TCP involves various attempts to game the TCP expected behaviour
16:30:43 <ht> MB: SPDY tries to avoid this by addressing multiplexing, with prioritization, directly
16:31:31 <Yves> problem in doing multiplexing at the spdy level (or httpmux earlier) is the bad interaction that might happen between the tcp window size and the chunk size at l7. 
16:31:33 <ht> MB: Google research found that when there are packet losses, having two connections is a real win
16:32:21 <ht> MB: Multiplexing uses fewer connections which overall simplifies things
16:32:31 <ht> MB: Performance == minimal latency
16:32:57 <ht> NM: Trying to get this via multiple connections did seem to make things worse
16:33:11 <ht> MB: Wins with NAT as well
16:33:40 <ht> MB: Two connections is already recommended in 1.1 [HTTP?]
16:34:13 <Yves> note that the number of // connections in http has been removed in httpbis (as it was not relfecting the reality of things)
16:34:31 <ht> MB: When that got multiplied by separate hosts for e.g. js and jpg, and then 2 per went to 6 per, suddenly we were up to 12 --- 18 connections for a single page
16:35:12 <ht> TBL: TCP will back off and reroute if things get stuck
16:35:38 <ht> MB: We took a serious approach to this
16:35:55 <ht> MB: The average hosts hit per page is 8, rising 9
16:36:15 <ht> ... and the size has grown too
16:36:45 <ht> MB: Browsers are trading off resource fetching against page load performance
16:37:16 <ht> ... SPDY was trying to take that optimization off of browsers backs
16:37:52 <Yves> having mux helps against multiple tcp conn and badly implemented http pipelining.
16:37:57 <ht> MB: Important because the difficulty of modelling web pages has grown enormously
16:38:28 <ht> ... JS, CSS have execution times, so building benchmarks for web page latency is very tricky
16:38:42 <ht> ... Couldn't just use Chrome, because it already has a set of decisions built in
16:38:53 <ht> s/Couldn't/Didn't want to/
16:39:13 <ht> ... But building a platform from scratch for benchmarking was too big a job
16:39:42 <ht> ... So we did in the end build plugins for Chrome to benchmark SPDY and HTTP side-by-side
16:39:58 <ht> ... Very glad that we have Firefox now doing their own similar work
16:40:24 <ht> MB: First three are parallel to HTTP -- GET etc.
16:40:53 <ht> MB: Server push is different/new, which requires client- and server-level rework
16:41:16 <ht> ... We tried some experimental services using push
16:41:23 <ht> ... The cache is an issue
16:41:49 <ht> ... You have to understand the service/application detail, and you only get rid of one round-trip
16:41:58 <ht> ... Doesn't look like there's enough energy
16:42:33 <noah> HT: There are apps that make sense to build >if< you don't have to busy wait.
16:42:49 <noah> MB: which is kind of what we have today
16:42:58 <noah> HT: In HTTP 1.1 you can hang on a get.
16:43:12 <noah> NM: Yes, comet.
16:43:12 <noah> HT: But there were too many glitches.
16:43:41 <ht> MB: Yes -- GoogleDocs does mutual refresh by hanging gets
16:44:11 <ht> ... So if you have 30 GoogleDocs open, there's a problem with the limit of 6 connections per host
16:44:26 <ht> ... So GoogleDocs fakes it with multiple hosts :-(
16:44:42 <ht> ... SPDY multiplexing is enough to fix this
16:45:12 <ht> TBL: Shared editing experience everywhere would be really good
16:46:12 <ht> MB: Hanging get over SPDY is cheap, and does the job, so Server Push doesn't seem so urgent
16:47:13 <ht> MB: Server push is server-initiated
16:47:28 <ht> MB: Why SSL?  Well, SPDY doesn't _require_ SSL
16:47:56 <ht> ... First choice is TCP or UDP -- TCP, to save hassle
16:48:25 <ht> ... So, what port?  80 or 443 -- pipelining not really there for 80, pblms with proxies, slowly getting sorted out
16:49:03 <ht> NM: Problem would be that new stuff would confuse proxies if it went through port 80, right?
16:49:13 <ht> MB: Right
16:49:21 <ht> MB: So we went to 443
16:49:59 <ht> MB: And in any case, we came to feel that securing the Web was independently a good thing
16:50:43 <ht> [Various]: Certificates are broken, how to secure the web is a huge issue, maybe not in scope today
16:50:52 <ht> LM: What about IPv6?
16:51:19 <noah> TBL: For stuff that doesn't need to be secured, it's very tempting to get to a P2P solution.
16:51:20 <ht> TBL: But some things, say NYT front page or a TED video, which are truly public
16:51:36 <ht> TBL: is that destined for P2P, or some other architecture?
16:51:56 <ht> MB: You're right, we recognize that not everything should go this way
16:52:13 <ht> ... But operators are not very good at recognizing the difference
16:52:56 <ht> ... Even the front-page of the NYT is a simple case, if it's personalized to you on the basis of personal (private) info, then that _is_ important to keep secure
16:53:17 <Yves> encrypting everything is a double edged sword...
16:53:35 <ht> ... The Google China experience made us all very sensitive to the fact that personal data can in fact be a matter of life and death, and you never know where it's going to turn up
16:53:52 <timbl> (ages  ago .. TBL: Peter, you said when 1 TCP connection has losses and slows down it is faster to add a second connection. Of course, when there is congestion adding more connections adds to the congestion, which on a large scale when everyone does it once, could have overall very detrimental  effect on latency for everyone else.  So one should simulate or measure the effcet of doing this to everyone on the net )
16:53:54 <ht> MB: The whole security layer needs improvement
16:54:29 <ht> ... both in terms of security as such, and in terms of speed
16:54:34 <ht> MB: What about proxies?
16:54:44 <noah> I think this will drive ubiquitous inclusion of SSL acceleration in hardware, something I've thought for a long time would be a good enabling step
16:55:26 <ht> MB: On the back end, inside firewall, use SPDY w/o SSL
16:55:48 <ht> MB: Proxies are a good thing, and SPDY doesn't have a story about how to play nice with proxies
16:56:12 <ht> ... SPDY does not address cacheable secured content
16:56:36 <ht> MB: But everyone is using CDNs, which have largely overtaken proxies for many large operators
16:56:54 <ht> MB: But this lack is a weakness for SPDY
16:57:19 <noah> I think it's really large organizations that are deploying CDNs...you prejudice against the long tail when you assume that everything accessed from distant locations is sourced by a large organization like CNN or Google
16:57:20 <ht> LM: We need an analysis of what the impact of not being able to cache actually is
16:58:19 <ht> MB: Right -- what's the impact in aggregate -- even though there are clear cases where it loses on an individual basis
16:59:26 <ht> NM: For the original pre-CDN [Content Distribution Network] world, your ISP got you pages that started a long way away quickly
16:59:46 <ht> ... That won't work 
17:00:01 <ht> s/work/work with SPDY/
17:00:28 <ht> LM: Right, so that's why some more global measurement and analysis required
17:00:45 <ht> MB: And of course any SSL use today is already not proxied
17:01:37 <ht> MB: With SNI, you can see the hostname, but not in vanilla SSL, which makes virtual hosting difficult
17:01:38 <noah> LM: Corporations may not be happy with the loss of filtering capability that follows from ubiquitous SSL usage
17:01:44 <Yves> java doesn't have SNI as well :(
17:01:44 <ht> present+ Rigo Wenning
17:02:12 <ht> PL: Moving to signed content is another important avenue to look at, necessary for [what?]
17:02:24 <plinss> peer to peer failover for http
17:02:56 <ht> MB: There are a lot of horror stories out there from big sites about proxy badnesses
17:03:13 <ht> ... SSL removes that vulnerability
17:04:21 <ht> MB: The mobile operators have this lose-lose tradeoff between idiosyncratic compression (fast but potentially bad on the device) vs. not (slow but reliable on the device)
17:04:59 <ht> MB: Patrick McManus of Firefox has looked at some numbers
17:05:20 <ht> ... 83 connections for the NYT home page puts really bad pressure on NAT
17:06:26 <ht> MB: But the NAT things cuts both ways -- dependence on a single channel makes NAT dropout more noticeable/serious
17:07:35 <ht> MB: Speculation about Kindle Fire -- you could push the multiplexing out to the Amazon connection point at EC2
17:08:03 <ht> ... So that _all_ traffic goes via a single connection (over 443) from the Kindle customer
17:08:37 <ht> ... This appears to contradict the end-to-end story SSL demands
17:08:52 <ht> ... Requires the notion of trusted proxy -- SSL man-in-the-middle
17:09:22 <ht> ... So, and explicit proxy: Kindle to EC2, or anyone to their corporate firewall
17:10:16 <RRSAgent> RRSAgent has joined #tagmem
17:10:16 <RRSAgent> logging to http://www.w3.org/2011/11/04-tagmem-irc
17:15:30 <RRSAgent> RRSAgent has joined #tagmem
17:15:30 <RRSAgent> logging to http://www.w3.org/2011/11/04-tagmem-irc
17:16:15 <ht> MB: Yes, there is a potential for head-of-line blocking, which can amplify in certain cases
17:16:15 <ht> ... But overall we are still winning
17:16:58 <ht> MB: It's difficult to model this, you have to collect empirical data
17:17:17 <ht> ... No doubt that with multiple streams, you are more vulnerable
17:17:47 <ht> ... I think there are some TCP tweaks that can help, we're working on it
17:18:19 <DKA> q?
17:18:29 <ht> MB: [Stuff about 'slow startup' which scribe didn't get]
17:19:44 <ht> NM: Adding another stream to SPDY doesn't allow cross-stream fixup, right?
17:19:50 <ht> MB: Yes
17:20:11 <ht> MB: SPDY does in general fix the head-of-line blocking problem
17:20:33 <ht> ... Firefox guys have been trying to get pipelining working better, but it's really hard
17:20:42 <ht> ... They presented at IETF last year [ref?
17:21:26 <ht> MB: We were pushed to start all the way down at the packet protocol level, but resisted
17:21:32 <timbl> q+ about conection to the web layer with content-type, link: relmeta etc
17:21:42 <timbl> q+ to about conection to the web layer with content-type, link: relmeta etc
17:22:12 <ht> MB: We think there's a lot of room to optimize on top of TCP, and we'll only look downwards after that's worked through
17:23:16 <ht> DKA: SO standardization -- What does take this to IETF in 2012 mean in detail?  SHould the TAG stay involved, and if so why -- in what way does it impact on Web Arch
17:23:23 <ht> s/Arch/Arch?/
17:23:54 <ht> NM: Yes, I think TAG should stay involved, but we should discuss this on a telcon
17:24:37 <noah> ACTION: Noah to schedule discussion of how, if at all, TAG should continue to be involved with SPDY
17:24:37 <trackbot> Created ACTION-626 - Schedule discussion of how, if at all, TAG should continue to be involved with SPDY [on Noah Mendelsohn - due 2011-11-11].
17:24:45 <ht> TBL: At the Web level, things such as Content type, the Link header, things like that
17:24:57 <ht> ... Does SPDY change that?  Where are HTTP headers?
17:25:11 <ht> MB: Almost entirely untouched
17:25:28 <ht> ... So the framing layer is pretty much all that changes
17:26:28 <ht> MB: We looked at 'improving' some aspects of HTTP -- absolutizing all URIs
17:26:39 <ht> ... but there are some servers which don't support it
17:27:13 <ht> TBL: Absolute URIs can indeed be problematic
17:27:35 <ht> LM: HTTP 1.1 really require support?
17:27:40 <ht> [Various]: Yes
17:27:59 <ht> MB: Net-net on that -- we backed off doing anything like that
17:28:30 <ht> MB: Not yet sure how we go to IETF, exploring that with PStA
17:29:23 <ht> LM: SPDY sounds extremely immature to me -- the impact of this on a wide scale, outside Chrome<->Google servers, is just unknown
17:29:50 <ht> ... W3C used to have resources in this area, it would be good to have W3C involved in taking something _like_ this forward
17:30:11 <ht> ... Without any guarantee that the outcome will be much like SPDY
17:30:37 <ht> LM: But I'd prefer to start with more exploration of the requirements and consequences
17:31:14 <ht> NM: W3C should do this?  My sense is that we've been happy with IETF take the lead
17:31:22 <ht> s/take/taking/
17:31:58 <ht> LM: Well, comparing two protocols wrt 'page load latency' is a W3C area
17:32:42 <ht> LM: 'Doing this' will involve a lot of different tasks - "What does the Web require in terms of optimization" is a W3C issue, almost by definition
17:32:58 <ht> TBL: Yes
17:33:20 <ht> NM: So, push back on taking it to IETF?
17:33:33 <ht> TBL: No, makes sense to do the protocol there, as LM said
17:34:15 <ht> TBL: Low-level q -- Can the client change its mind about priority?
17:34:41 <ht> MB: Change-priority is not supported, but tab-change might provoke us to rethink that
17:34:57 <ht> ... Note that the priorities are advisory, the server can do whatever it likes
17:35:38 <timbl> chrome://net-internals/#spdy
17:35:50 <ht> MB: Wrt standardization and changes -- putting it out there means Google understands that other perspectives are now needed, and will lead to changes
17:36:11 <ht> NM: Need to stop, so thanks to Mike
17:36:33 <ht> ... the TAG will come back to this -- who do we feed back to?
17:36:57 <masinter> masinter has joined #tagmem
17:37:28 <noah> http://groups.google.com/group/spdy-dev
17:37:38 <noah> Send email to this group: spdy-dev@googlegroups.com
17:38:01 <masinter> s/I'd prefer to start with more/I think a prerequisite for standardization is more/
17:38:02 <noah> HT: I think the W3C IETF liaison needs to be aware of this, and help us decide where the W3C needs to be involved
17:38:57 <ht> NM: Suspended until 1050
17:45:12 <jar> zakim: "the conference is restricted at this time"
17:55:02 <ht> zakim, who is on the call?
17:55:02 <Zakim> On the phone I see no one
17:55:35 <Zakim> Team_(tagmem)16:13Z has ended
17:55:36 <Zakim> Attendees were 
17:56:13 <ht> zakim, room for 3 for 90 minutes?
17:56:14 <Zakim> ok, ht; conference Team_(tagmem)17:56Z scheduled with code 26631 (CONF1) for 90 minutes until 1926Z
17:57:20 <jar> zakim says "this conf is restricted"
18:02:19 <timbl> Zakim, please dial ponderosa
18:02:19 <Zakim> ok, timbl; the call is being made
18:02:20 <Zakim> Team_(tagmem)17:56Z has now started
18:02:32 <timbl> Zakim, thaks
18:02:32 <Zakim> I don't understand 'thaks', timbl
18:02:36 <ht> Hmm, that worked
18:02:36 <timbl> Zakim, thanks
18:02:36 <Zakim> you are very welcome, timbl
18:02:37 <plinss> zakim, code?
18:02:37 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plinss
18:03:12 <timbl> We are on the bridge from Zakim dial out
18:03:13 <jar> "restricted at this time"
18:03:13 <ht> NM: Resuming
18:03:17 <timbl> darn
18:03:19 <ht> Topic: Copyright and Publishing on the wab
18:03:28 <ht> s/wab/Web/
18:04:53 <noah> http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2011-10-27.html
18:05:35 <ht> s/Copyright and Publishing/Publishing and Linking/
18:06:21 <ht> DKA: [introduces the above doc]
18:06:22 <Zakim> Team_(tagmem)17:56Z has ended
18:06:23 <Zakim> Attendees were 
18:06:55 <ht> present+ JAR
18:07:30 <ht> present+ Rigo Wenning
18:07:59 <Ashok> q+
18:11:27 <Ashok> q-
18:11:55 <ht> DKA: Questions for Rigo -- Is the overall goal sensible/useful; Are there other terms we should add, e.g. 'performance'; Are there other regulatory/policy issues we should add to the framing?
18:12:36 <ht> LM: Great start, ready to figure out what the next steps are
18:12:53 <ht> ... To be useful, this has to be published in a way that gets community consensus
18:13:02 <ht> ... How do we get there
18:13:54 <masinter> the TAG could publish it as a NOTE and start a community group?
18:14:12 <ht> NM: Maybe we should schedule detailed review of this at some length at the January F2F
18:14:22 <noah> ACTION: Noah to schedule very detailed line-by-line review of Pub&Linking draft at January F2F
18:14:22 <trackbot> Created ACTION-627 - Schedule very detailed line-by-line review of Pub&Linking draft at January F2F [on Noah Mendelsohn - due 2011-11-11].
18:14:26 <ht> LM: Can we get the TAG out of the critical path?
18:14:39 <jar> but we wanted this to go rec track.
18:14:41 <ht> ... Community group, which might have some lawyers in it
18:15:00 <ht> RW: The scope of this document is too large
18:15:00 <jar> Thinh says effectiveness much enhanced by rec status
18:15:19 <noah> I would prefer to focus on linking
18:15:22 <ht> RW: Publishing is a nightmare, and linking even more so
18:15:42 <ht> RW: Legal tactic is to partition as much as possible
18:15:44 <tlr> tlr has joined #tagmem
18:16:16 <ht> RW: Reduce this, make two documents
18:16:24 <jar> jar to rw: this is not a legal document
18:16:26 <ht> DKA: Start with linking?
18:16:29 <ht> RW: Yes
18:17:00 <jar> linksandlaw.com  - I've given out the pointer a few times
18:17:03 <ht> RW: Look at www.linksandlaw.com
18:17:34 <jar> q?
18:17:45 <noah> http://www.linksandlaw.com/linkingcases.htm
18:17:54 <ht> RW: there are a very large number of relevant cases
18:18:12 <ht> LM: Would you help if you were tasked to do so?
18:18:47 <ht> RW: Your first document, to get the story clear, is not for the world
18:18:57 <ht> TBL: Why not for the world?
18:18:57 <masinter> s/Would you help/Would you come to the TAG to help/
18:19:16 <ht> RW: If you talk too much, your central message goes away [tip of the hat to TLR]
18:19:18 <masinter> s/TAG to help/TAG for help/
18:20:00 <ht> NM: Advice could focus on "if ... then ..." heads-up kinds of observations
18:20:16 <jar> q?
18:20:20 <ht> RW: There is a long-standing conflict between the technical and legal communities
18:20:38 <jar> q+ jar
18:20:59 <ht> RW: There are already laws, with terminology definitions
18:21:03 <masinter> I think we should take what we have and see how we can make it useful....
18:21:17 <ht> RW: so there's a conflict over ownership of terms
18:21:35 <ht> LM: I just want to make this useful enough to publish
18:21:53 <ht> ... Suppose this is just an outline of what the TAG understands in this space
18:22:13 <ht> ... And accepting that we can't resolve the conflicts
18:22:16 <ht> ... Could we point out where the conflicts _are_?
18:22:47 <ht> RW: If you asked me, I would try to come up with a concise statement of the fact that publication implies the possibility of linking to
18:23:13 <ht> RW: See e.g. the KPMG example from linksandlaw
18:23:30 <jar> oops, I had promised to write something about "don't link" terms of use
18:23:39 <noah> http://www.linksandlaw.com/linkingcases-linkingpolicies.htm#KPMG
18:23:52 <jar> look at the american airlines site (whose URL I can't give you)
18:24:14 <jar> q?
18:24:14 <ht> RW: Not stop this document, to get our own understanding clear
18:24:20 <ht> ... but also publish simple short observations that are at the core
18:24:28 <ht> DKA: But that's a legal statement
18:24:48 <ht> NM: We set out to avoid to making policy statements
18:25:06 <jar> q?
18:25:29 <ht> NM: We can't state that publishing gives a right to others to link
18:25:51 <ht> RW: Not a right, but [???]
18:26:13 <ht> TBL: You're preaching to the choir, but how do we say this?
18:26:26 <jar> ht, can you ask the chair to look at the q?
18:27:03 <ht> RW: We can distinguish between linking itself and the existence of access control
18:27:27 <ht> NM: [Hypothetical KPMG example]
18:28:13 <ht> NM: How do we make it a technical observation, not a policy one
18:29:37 <ht> RW: The fact that you include a pointer to something on the Web in your document has no meaning for the content over there, and is completely unrelated to the thing identified
18:30:23 <ht> TBL: If you can from the KPMG home page browse to another page, I should be able to pass that link to someone else
18:32:11 <ht> TBL: The UK position appears to be that publishing a link collection to pirate music sites is to be an accessory to copyright theft
18:33:01 <ht> TBL: We could try reciprocal banning, by notifying KPMG that they are not allowed to read the W3C site
18:35:00 <ht> JAR: Wrt what RW and LM said, the original idea, from Thinh Win, was that it would be useful, to forestall bad decisions, if there was a document that simply stated what the _technical_ community thinks these terms mean.
18:35:21 <ht> ... Thinh went on to say that to get the necessary impact, it needs to go out as a REC
18:35:49 <ht> JAR: So it doesn't try to argue with the law, it just says what the technical understanding of these terms is
18:36:48 <ht> DKA: So we started from there, and the fact that a URI is public identifier, to get to the parallel between speech acts and URI use, and that brings in the 'right to link', parallel to free speech
18:37:13 <ht> ... from which we got drawn in to the distinction between linking and embedding
18:37:14 <jar> s/ Win/ Nguyen/
18:37:45 <ht> DKA: And getting embedding clear requires us to get the publishing/hosting distinction clear
18:38:39 <ht> DKA: Because it isn't clear that a page with text and video involves multiple sources
18:38:55 <ht> RW: The legal side knows about this
18:39:12 <ht> DKA: So, maybe we _don't_ need all of that?
18:39:38 <ht> NM: We're getting different advice from different legal sources. . .
18:40:22 <ht> AM: Alternatively, maybe we should not publish a TAG doc't, but something in the popular space, e.g. the NYT over Tim's byline
18:40:34 <masinter> so we should make a short statement around which we can get consensus, focused on one small issue around linking and copyright
18:40:51 <masinter> at least that's what Rigo is advocating
18:40:53 <ht> RW: The TAG endorsement of a short statement about the passive linking case which is constitutive of the Web
18:41:13 <ht> s/of/should be of/
18:41:13 <jar> session with Thinh: http://www.w3.org/2001/tag/2010/12/02-minutes.html#item01  ...
18:41:35 <ht> AM: If we did a short statement, how do we get it out? To make an impact?
18:41:39 <masinter> the current document is useful for us, but way to broad.
18:42:00 <ht> RW: The publication channel of the TAG itself should be ordinary, which has our opinion
18:42:11 <ht> LM: It could be a finding
18:42:24 <ht> RW: And then you go to the NYT and say "The TAG has said. . ."
18:43:47 <timbl> q+
18:43:53 <jar> ack jar
18:43:54 <ht> NM: If the W3C/the membership/TBL want to say [a quasi-hortatory claim about the right to link], that's fine, but it's not for the TAG to do so
18:44:14 <ht> ack next
18:44:17 <ht> NM: The TAG does architecture
18:44:33 <ht> TBL: But the architecture has a fundamental social component
18:44:49 <masinter> i think this can be a finding, making a statement about the architectural assumption of the web and underlying many of the TAG's other activities is that linking is fundamental, that providing URIs for content is recommended, excatly tot promote linking
18:44:59 <ht> ... Spam is a social violation of the architecture
18:45:32 <ht> TBL: So I think the TAG can speak on this subject in social terms
18:46:15 <ht> NM: Yes, I'm comfortable with talking about social value, and the impact of policy on value
18:46:42 <ht> TBL: Forbiding incoming links breaks the [social] system
18:47:42 <ht> NM: But there are clearly (jurisdictional bounded) cases where linking to unacceptable material is itself unacceptable
18:48:00 <ht> LM: We haven't said anything about laws
18:48:24 <ht> TBL: But we are close to that in saying KPMG are doing something wrong
18:49:01 <ht> RW: Wrt DKA's point, using the free speech analogy is going further that I would
18:49:15 <masinter> we have designed the system such that linkability is a benefit. Attempts to restrict linkability is counter to the effective use of the system as designed.
18:49:52 <ht> RW: I would focus on the passive case: it's wrong for sites to pubish rules which forbid linking to them
18:50:37 <masinter> we don't have to say "the law is a bad idea", we have to point out the negative consequences of such laws
18:50:44 <jar> TN: default rules are important in court... may be supplied by technical standards
18:51:06 <jar> (that was Thinh last December)
18:51:31 <ht> LM: Trying to avoid value judgements, but just say what the consequences of doing so would
18:51:45 <jar> The consequences speak for themselves. Generally speaking.
18:52:33 <ht> NM: I want to focus on the consequences of laws which enable behaviours
18:53:11 <ht> HST: THat's much narrower than I hear from JAR and LM, who are happy to discuss consequences of actions, not just laws (or not laws at all)
18:53:37 <ht> NM: Look at the KPMG case -- it's going to get legal very quickly
18:53:59 <ht> ... Immediately the question will arise as to whether their statement is enforceable by law
18:54:29 <ht> RW: As Thinh Nguyen said, the legal interpretation will be based on usage, on community habits
18:54:30 <jar> yes laws
18:54:50 <ht> ... Is the expectation in practice that certain things hold
18:55:12 <ht> ... So the shrink-wrap story was surprising, contrary to expectation
18:55:26 <masinter> i would still like to see Jeni/Dan's document published as a note after review, even if we also have a finding about common use of linking and the TAG's position on it
18:55:40 <ht> ... Similarly the expectation is that publishing something on the Web gives the expectation of linking
18:56:11 <ht> s/expectation of/possibility of/
18:56:58 <masinter> it gives the possibility of linking, and we've encouraged that
18:57:44 <ht> JAR: I actually do think it makes sense for a technical person to say that "operating under such-and-such a restriction would have the following [bad] consequences", so I'm not ruling out laws
18:57:51 <noah> +1 to what Jonathan just said
18:57:58 <masinter> i'm trying to distinguish between "such restrictions are bad" and "negative consequences  of such restrictions are X, Y, Z; such restrictions are bad if they do not have clear redeeming value"
18:58:12 <ht> HST: OK, I see a continuum, was a mistake to try to push for two distinct positions
18:58:32 <masinter> the web was designed for X, it was built with this assumption
18:59:00 <ht> DKA: Saying "restricting linking will have a detrimental effect on the Web" is weak from a legal perspective -- The lawyer will say "Not my problem"
18:59:12 <noah> What I want to rule out, mostly, is: "law XXX should not be passed". I would rather say: "if you pass law XXX, you should understand that the consequences to the operation of the system, and to its positive social value will be YYY"
19:00:12 <masinter> restrictions on linking are impossible to accomplish because of web architecture? search, robots.txt, harvesting, ...?
19:00:12 <ht> DKA: We're not asking for unrestricted freedom to link, but no less freedom than the freedom of speech
19:00:51 <ht> NM: The speech parallel is weak, because URIs don't point to consistent things necessarily
19:01:14 <ht> ... I prefer the address analogy
19:01:30 <masinter> we should be clearer about who the primary audience is for this finding
19:01:56 <ht> NM: COnsider the address of [a prohibited organization] in a public works document about street repairs to in a list of recommended destinations
19:02:28 <masinter> maybe a blog post? 
19:03:45 <ht> NM: So consider a log of URIs versus a Web page which references it
19:04:22 <ht> LM: Summarizing RW -- the scope of this document is too broad, you should find a few one-page extracts
19:04:46 <ht> DKA: I'll take this back to Jeni and consider all of the input we've gotten
19:05:12 <ht> ... And decide whether to take this forward broadly but internally
19:05:19 <ht> ... or whether we can pare it down effectively
19:05:31 <ht> NM: There are clearly different opinions about:
19:05:40 <ht> ... 1) What the goal of the document is;
19:05:53 <ht> ... 2) What its scope is.
19:06:21 <ht> NM: We should acknowledge the lack of consensus, and maybe the divergence of advice we're getting
19:06:48 <timbl_> timbl_ has joined #tagmem
19:06:51 <ht> RW: Pursuing (w/o publishing) this document, will improve the value of TAG utterances in the future
19:07:31 <ht> RW: That the passive case: I'm a site, and I forbid linking, is wrong is what you should say
19:07:44 <ht> ... _not_ the active "I have a right to link"
19:07:58 <ht> ... The latter gets quickly extremely messy
19:08:12 <ht> NM: Thank you Rigo
19:08:15 <ht> Present+ Chris Lilley
19:11:12 <ht> Topic: 3023bis -- Media type registration for the XML family
19:11:39 <ht> CL: I've mailed a summary of recent progress on 3023bis to www-tag
19:11:45 <masinter> masinter has joined #tagmem
19:11:55 <ht> CL: Previous draft deprecated text/xml
19:12:20 <ht> CL: Implementors pushed back, as we have to support it even if new authors don't use it
19:12:41 <ht> CL: I took this to IETF80, got lots of interaction
19:13:17 <ht> CL: HTTPbis then removed the default charset handling rules, which is consistent with applications today
19:13:40 <ht> CL: But that left email out of sync with HTTP
19:14:49 <ht> CL: But but it now appears there is willingness to fix the text/... story to allow individual text/ media types to declare their own charset rules
19:15:15 <ht> CL: So text/xml can say there is no default charset and the XML spec rules determine
19:15:19 <tlr> tlr has joined #tagmem
19:15:34 <ht> LM: So, what is in the way of publication?
19:16:12 <ht> CL: On this front, nothing, but the fragid situation is still pending
19:16:49 <ht> JAR: xhtml+xml can have RDFa in it
19:17:03 <ht> HST: What's the problem with that?
19:18:01 <noah> HT: What's the bad case?
19:19:44 <ht> JAR: The case is this -- you have a URI with a fragid, and you want to follow your nose
19:20:15 <ht> ... If you look at the 3023bis registration, it says XPointer tells you the semantics
19:20:26 <ht> ... so you look for an ID, and don't find one
19:20:35 <ht> ... So there's an error (per XPOinter)
19:23:17 <jar> The no new syntax move, for SVG...
19:23:45 <jar> if syntax is not a valid xpointer, then defer to the specific media type reg
19:24:23 <jar> the xhtml media type has to say something about RDFa...
19:24:31 <jar> and 3023 needs an override policy
19:24:47 <jar> (scribing, should have been prefixing ht: to most of those)
19:25:49 <jar> jar: the new piece for me was realizing that we need to also talk about application/xhtml+xml
19:26:14 <jar> ht: 3023bis says it *is* the definitive spec for fragids
19:27:07 <jar> ht: what it needs to do is to say under what circumstances it defers to the subsidiary media type reg
19:27:18 <masinter> why is this on critical path for 3023bis ?
19:27:27 <ht> trackbot, status?
19:28:22 <ht> ACTION Henry to work with Chris Lilley to bring forward prose for 3023bis wrt generic processing of fragment identifiers which addresses the rdf+xml and xhtml+xml issues
19:28:23 <trackbot> Created ACTION-628 - Work with Chris Lilley to bring forward prose for 3023bis wrt generic processing of fragment identifiers which addresses the rdf+xml and xhtml+xml issues [on Henry Thompson - due 2011-11-11].
19:28:42 <ht> ACTION-628 due 2011-12-31
19:28:42 <trackbot> ACTION-628 Work with Chris Lilley to bring forward prose for 3023bis wrt generic processing of fragment identifiers which addresses the rdf+xml and xhtml+xml issues due date now 2011-12-31
19:29:49 <noah> That's fine, Henry, assuming you'll also put in the cover email a bit of framing to remind something about the history and context for whatever is proposed
19:30:50 <ht> LM: Isn't this a general point abou tmixins
19:30:50 <masinter> use of RDFa as a mixin applies to more things, like JSON
19:31:02 <ht> s/abou tmixins/about mixins/
19:31:33 <ht> LM: Can't we get some cleaner layering?
19:32:52 <ht> NM: In the interest of getting 3023bis out, can't we do this locally first, in 3023bis, on the assumption that it will be consistent with any cleaner general solution
19:33:19 <ht> LM: Getting mixins right is likely to be a huge problem, you're going to get stuck in a tarpit
19:33:39 <ht> CL: You may be right, we'll see
19:34:21 <ht> LM: The way to get follow-your-nose for mixins requires you to modify the host-language media type definitions systematically
19:34:57 <jar> ht: In my recent email I distinguish between "witting" and "unwitting" host languages
19:35:37 <jar> … any attribute on any element, as long as it's in a namespace that's not ours
19:35:38 <noah> HT: In my email on RDFa I distinguished between "witting" and "unwitting" host languages. The former work easily, but the latter are important. There are languages that say things like: "any attribute/element here", and I don't want to have to call it out explicitly in my spec
19:35:47 <masinter> are there other mixins other than RDFa that add fragment identifier possibilities?
19:36:17 <masinter> can i mix-in SVG into something and use SVG visible objects as fragment targets?
19:37:14 <ht> HST: 'Unwitting' embedding of RDFa can't trigger a change to a media type registration
19:38:26 <ht> LM: But unwitting embedding of e.g. SVG would introduce the possibility of using SVG-style fragids which only work in the SVG sub-part
19:38:46 <masinter> s/sub-part/sub-part?/
19:38:52 <ht> NM: There is at least some discussion of that case in the Self-describing Web finding
19:39:00 <masinter> s/But/Does/
19:39:12 <ht> TBL: This comes under the XML functions story as well
19:39:49 <ht> LM: So, go ahead, but be aware that there be dragons
19:40:13 <ht> Topic: Web Storage
19:40:14 <ht> AM: There is a Web Storage Last Call WD just out
19:40:27 <ht> ... We need to decide whether we want to comment
19:41:41 <ht> Topic: [L&P returns]
19:42:11 <ht> HST: I'm not sure sending the editors off to work harder when the TAG hasn't agreed on scope is an invitation to waste time
19:43:12 <ht> DKA: I wasn't going to dive right in to cut the document down -- I want to work with _all_ the feedback we've gotten this week, particularly on Wednesday, and that's what I want to work with
19:43:29 <ht> s/what I want to work with/where I want to focus/
19:45:42 <ht> LM: So a new draft is worth working on if it yields something we can publish
19:46:31 <ht> NM: Remember Goals and Success Criteria -- we should keep these (http://www.w3.org/2001/tag/products/PublishingLinking.html) in mind
19:46:42 <ht> NM: And consider revising them too
19:46:49 <noah> ACTION: Appelquist with help from Jeni to propose changes to goals, success criteria etc. for publishing/linking product page
19:46:49 <trackbot> Created ACTION-629 - With help from Jeni to propose changes to goals, success criteria etc. for publishing/linking product page [on Daniel Appelquist - due 2011-11-11].
19:47:23 <ht> LM: Right -- for example split the work between a small 'official' publication and a larger background unofficial 'white paper'
19:51:12 <ht> RRSAgent, make logs world-visible
20:28:32 <tlr> tlr has joined #tagmem
20:37:21 <ht> ht has joined #tagmem
21:12:32 <Zakim> Zakim has left #tagmem
21:20:45 <plinss> plinss has joined #tagmem
21:24:13 <tlr> tlr has joined #tagmem
21:25:19 <ht> ht has joined #tagmem
21:29:46 <tlr> tlr has joined #tagmem
21:43:41 <tlr> tlr has joined #tagmem
21:47:42 <timbl> timbl has joined #tagmem
22:10:55 <jar> rrsagent, pointer
22:10:55 <RRSAgent> See http://www.w3.org/2011/11/04-tagmem-irc#T22-10-55
22:40:38 <plinss> plinss has joined #tagmem
22:46:52 <plinss> plinss has joined #tagmem
22:47:01 <plinss> plinss has joined #tagmem
22:48:21 <plinss_> plinss_ has joined #tagmem
22:50:20 <plinss__> plinss__ has joined #tagmem
22:57:13 <plinss> plinss has joined #tagmem
23:00:40 <plinss__> plinss__ has joined #tagmem
23:01:29 <plinss__> plinss__ has joined #tagmem
23:02:13 <plinss__> plinss__ has joined #tagmem
23:11:47 <ht> ht has joined #tagmem
23:18:04 <ht> ht has left #tagmem
00:13:29 <noah> noah has joined #tagmem