IRC log of tagmem on 2012-01-06
Timestamps are in UTC.
- 14:07:24 [RRSAgent]
- RRSAgent has joined #tagmem
- 14:07:24 [RRSAgent]
- logging to http://www.w3.org/2012/01/06-tagmem-irc
- 14:07:26 [trackbot]
- RRSAgent, make logs public
- 14:07:26 [Zakim]
- Zakim has joined #tagmem
- 14:07:28 [trackbot]
- Zakim, this will be TAG
- 14:07:28 [Zakim]
- ok, trackbot; I see TAG_f2f()7:30AM scheduled to start 97 minutes ago
- 14:07:29 [trackbot]
- Meeting: Technical Architecture Group Teleconference
- 14:07:29 [trackbot]
- Date: 06 January 2012
- 14:08:10 [masinter]
- masinter has joined #tagmem
- 14:08:16 [JeniT]
- Scribe: Jeni
- 14:08:19 [JeniT]
- ScribeNick: JeniT
- 14:09:22 [Ashok]
- Ashok has joined #tagmem
- 14:09:36 [JeniT]
- Topic: Mime and the Web (with Mark Nottingham)
- 14:09:55 [mnot]
- mnot has joined #tagmem
- 14:17:00 [JeniT]
- (introductions)
- 14:17:32 [JeniT]
- mnot: chairing HTTPbis, liaison from IETF to W3C
- 14:20:11 [JeniT]
- mnot: "Web Linking" spec is an attempt to respecify Link: header
- 14:20:26 [JeniT]
- ... lots of requirements for link-based protocols
- 14:20:30 [JeniT]
- ... and typed links
- 14:20:48 [JeniT]
- ... for example in HTML rel="stylesheet"
- 14:21:07 [JeniT]
- ... Atom used link relations as well
- 14:21:19 [JeniT]
- ... and there's a registry and an XML syntax for links and link relations
- 14:21:26 [JeniT]
- ... eg copyright statements, next/previous links
- 14:21:48 [JeniT]
- ... wanted to revive Link: HTTP header
- 14:22:43 [JeniT]
- ... to convey links in headers rather than body of the message
- 14:22:57 [JeniT]
- ... HTML had linking, Atom had linking, and they weren't matched
- 14:23:20 [JeniT]
- ... RFC provides a model that you can serialise in various ways
- 14:23:27 [JeniT]
- ... needs a context, a type, and a target
- 14:23:49 [JeniT]
- ... (which you could map to RDF if you wanted to)
- 14:24:00 [JeniT]
- jar: is that called out anywhere?
- 14:24:04 [JeniT]
- mnot: not particularly
- 14:24:23 [JeniT]
- ... and so to registration
- 14:24:30 [JeniT]
- ... link types being a particular example
- 14:24:35 [JeniT]
- ... we felt there should be one registry
- 14:24:48 [JeniT]
- ... the HTML groups wanted to use a wiki
- 14:25:09 [JeniT]
- ... we felt that was too freeform, and noisy
- 14:25:21 [JeniT]
- ... and could lead to changing semantics in a backwards-incompatible way
- 14:25:31 [JeniT]
- ... so we tried to address their concerns in the registry
- 14:25:50 [JeniT]
- ... but they (the HTML group) didn't feel it was an appropriate thing to use
- 14:25:53 [JeniT]
- ... time passes
- 14:26:06 [JeniT]
- ... the link relation registry is a lot of work to maintain
- 14:26:26 [JeniT]
- ... every interaction requires discussion with the author
- 14:26:48 [JeniT]
- noah: the overhead is high but the rate isn't high
- 14:26:59 [timbl]
- http://www.iana.org/assignments/link-relations/link-relations.xml
- 14:27:07 [JeniT]
- mnot: we would like to see a higher rate, but can't support it at that overhead
- 14:27:15 [JeniT]
- jar: this is the same issue in journal publication
- 14:27:26 [JeniT]
- mnot: the question is whether value is being added
- 14:27:41 [JeniT]
- ... we have a common system of expert review in IETF
- 14:27:54 [JeniT]
- ... the underlying question is what is registry for?
- 14:28:09 [JeniT]
- ... some people see it as a gating function: if it's not registered, then it won't be used
- 14:28:18 [JeniT]
- ... to prevent stuff that is bad from being used
- 14:28:29 [JeniT]
- ... but the gating function makes people less likely to use the registry
- 14:28:45 [JeniT]
- noah: so people go ahead and do it anyway, without using the registry
- 14:29:06 [JeniT]
- mnot: we discovered this was common to registries for media types, link relations, HTTP headers and URI schemes
- 14:29:14 [JeniT]
- ... talked to Ned Freed
- 14:29:36 [JeniT]
- ... who runs the media type registry
- 14:29:46 [JeniT]
- ... saw that people were misinterpreting the function of registries
- 14:29:56 [JeniT]
- ... actually the registry should reflect what is in use
- 14:30:28 [JeniT]
- noah: is there a middle ground?
- 14:30:47 [JeniT]
- mnot: for a lot of people, registry is just a barrier to get past
- 14:30:54 [JeniT]
- ... especially because the work is all up-front
- 14:31:21 [JeniT]
- noah: no one says they would deploy more quickly if it was registered
- 14:31:28 [JeniT]
- mnot: there's no benefit in the registration
- 14:31:36 [JeniT]
- masinter: it just exposes you to criticism
- 14:31:52 [JeniT]
- timbl: text/n3 is an example for me
- 14:32:17 [JeniT]
- ... the best practice was to use Turtle, but people would use application/rdf+xml because it was registered
- 14:32:31 [JeniT]
- mnot: people who pay attention to standards might care
- 14:32:43 [JeniT]
- timbl: getting media types into Apache does have a big effect
- 14:32:56 [JeniT]
- mnot: Apache put lots of stuff in, it's driven by the market
- 14:33:23 [JeniT]
- timbl: why does Apache work and the registry not?
- 14:33:45 [JeniT]
- mnot: we want to create a virtuous cycle, for example with machine-readable registry data
- 14:34:02 [JeniT]
- ... for example for link relations that lets you add attributes to registry entries
- 14:34:12 [JeniT]
- ... so that a browser can see whether it's a link that could be followed
- 14:34:24 [JeniT]
- ... or archived and so on
- 14:34:45 [JeniT]
- ... so if I come up with a new link relation, and it's treated in a generic way
- 14:34:47 [timbl]
- s/why does Apache work and the registry not?/So Apache mime .types works and iana doesn't -- why doens't IANA use the same process as Apache?/
- 14:34:54 [JeniT]
- ... the browsers can have a more automated process for adding semantics
- 14:35:34 [JeniT]
- noah: we have to give Jeff Jaffe early warning about potential larger issues
- 14:36:09 [JeniT]
- ... it seems that there's a bigger story here about market forces driving standards
- 14:36:48 [JeniT]
- q+ to ask whether browsers will really pick up on this metadata automatically
- 14:37:13 [JeniT]
- mnot: what we want to do is make IANA a suitable place for these registries
- 14:37:21 [JeniT]
- ... which is complex, but worth trying
- 14:37:25 [noah]
- ack next
- 14:37:26 [Zakim]
- JeniT, you wanted to ask whether browsers will really pick up on this metadata automatically
- 14:38:29 [noah]
- JT: You spoke of browsers automatically going to registries and doing something useful with what they find. Do you have actual experience with people being willing to do that? I haven't seen it in my work on RDF.
- 14:38:53 [noah]
- mnot: My understanding is that Ian Hickson and Anne van Kesteren felt this would be very helpful in the registries
- 14:39:33 [noah]
- mnot: I think one aspect of the value is during the browser development and QA process, where those building a browser can pull from the central registry, do some work to integrate with their browser or tests, and then deploy.
- 14:40:11 [noah]
- LM: It's almost as if you want to have so much in the IANA registry that you would never want to use it real time.
- 14:40:23 [noah]
- mnot: Hmm. Probably if you do things real time there will be attack vectors.
- 14:40:41 [noah]
- JT: And the process for staying in sync is to do a pull every time they release the browser.
- 14:40:51 [noah]
- mnot: Yes, but they are on very quick update cycles now
- 14:41:13 [noah]
- mnot: Seems unlikely we'll see people automatically supporting new media type handlers.
- 14:41:29 [noah]
- LM: I think I've seen things where apps on phones can register for URI prefixes
- 14:41:34 [JeniT]
- ScribeNick: JeniT
- 14:42:07 [JeniT]
- noah: has anyone looked at associating some a Javascript handler with eg a link relation
- 14:42:33 [JeniT]
- ... which the browser could then use to handle links of those types
- 14:43:04 [JeniT]
- mnot: that's a bit speculative
- 14:43:23 [JeniT]
- ... we want to focus on a virtuous cycle where code can use the information in the registry
- 14:43:48 [JeniT]
- timbl: ontologies are link this
- 14:43:52 [JeniT]
- s/link/like
- 14:43:53 [JeniT]
- s/link/like/
- 14:44:15 [JeniT]
- mnot: the registry needs to reflect what's in use, not how things should be
- 14:44:21 [JeniT]
- ... you need to make the barrier to entry low
- 14:44:26 [JeniT]
- ... and iteration rapid
- 14:44:34 [JeniT]
- ... to incrementally improve the entry
- 14:44:56 [JeniT]
- noah: it sounds like you're going very far over to there being no barriers
- 14:45:10 [JeniT]
- ... towards something completely open like a wiki
- 14:45:31 [JeniT]
- ... I think it's more a shift towards that rather than going completely to the extreme
- 14:46:06 [JeniT]
- mnot: the problem is that expert reviewers have a tendancy to try to maintain quality and prevent new entries going in
- 14:46:07 [masinter]
- q?>
- 14:46:10 [masinter]
- q+
- 14:46:19 [noah]
- ack next
- 14:46:37 [JeniT]
- mastinter: registries have rows and columns
- 14:46:48 [JeniT]
- ... there's a column with 'review status' which people making the entry can't change
- 14:46:57 [JeniT]
- ... which can be 'unreviewed' or 'unacceptable'
- 14:47:03 [plh]
- plh has joined #tagmem
- 14:47:10 [noah]
- Philippe le Hegaret joins us in the meeting room
- 14:47:21 [JeniT]
- mnot: yes, we've talked about having a range of statuses
- 14:47:38 [JeniT]
- ... it comes down to having a process to manage the registry
- 14:47:56 [JeniT]
- ... if you have a wiki, that's going to happen because there are going to be conflicts within the community
- 14:48:20 [JeniT]
- ... and there will be cases where you can't tell what to do, where there are two implementations using the same name with different semantics
- 14:48:33 [mnot]
- http://www.w3.org/wiki/FriendlyRegistries
- 14:48:35 [JeniT]
- ... so we started having meetings within IETF, and have set up a mailing list
- 14:49:20 [JeniT]
- ... FriendlyRegistryProcess
- 14:50:02 [JeniT]
- ... for example, turning the expert reviewer into more of a community moderator than a gatekeeper
- 14:50:20 [JeniT]
- ... for example, Apple is using a bunch of URI schemes which aren't currently in the registry
- 14:50:35 [JeniT]
- noah: should one size fit all?
- 14:50:48 [JeniT]
- ... it might be different for URI schemes than for link relations
- 14:50:52 [timbl]
- q+
- 14:51:17 [JeniT]
- ... it might be that it has different technical consequences to introduce new URI schemes
- 14:51:38 [JeniT]
- ack timbl
- 14:52:01 [JeniT]
- timbl: there should be very few URI schemes added, but a larger number of media types
- 14:52:07 [JeniT]
- ... because that's how the system is designed
- 14:52:24 [JeniT]
- ... about switching to a model where you register what exists
- 14:52:34 [JeniT]
- ... that does avoid conflict
- 14:52:57 [JeniT]
- ... I would support a very open bug tracking system on the registry
- 14:53:20 [JeniT]
- ... suppose someone registers something, and that automatically opens up a bug tracker for them, so people could make comments on it
- 14:53:22 [masinter]
- q+ to encourage stepping back from calling "too many URI schemes" as "damage", as there is no evidence of harm here. (pointing out I was trying to work on this in http://www.w3.org/2001/tag/2011/12/evolution/Registries.html
- 14:53:24 [JeniT]
- mnot: yes, we talked about this
- 14:53:56 [JeniT]
- timbl: not for the process of the registration, but to register technical issues
- 14:54:02 [JeniT]
- mnot: we talked about having a wiki page for each entry
- 14:54:13 [JeniT]
- ... there's a hidden bug tracker for IANA
- 14:54:55 [JeniT]
- timbl: tracker for issues about the entry
- 14:55:06 [JeniT]
- mnot: we do want to support third parties to register protocol elements
- 14:55:25 [JeniT]
- ... so if a company hasn't registered something, others can do it instead
- 14:55:45 [JeniT]
- timbl: ideally you want that to go through very fast, so that there can be feedback on the entry
- 14:55:55 [JeniT]
- mnot: and that comes back to the different statuses on the entries
- 14:56:10 [JeniT]
- ... to label that something has technical or legal issues
- 14:56:31 [JeniT]
- ... we want to order the entries to make the good ones more prominent
- 14:57:32 [masinter]
- q-
- 14:57:38 [JeniT]
- (moving on to next steps)
- 14:57:44 [noah]
- zakim, who is here?
- 14:57:44 [Zakim]
- TAG_f2f()7:30AM has not yet started, noah
- 14:57:45 [Zakim]
- On IRC I see plh, mnot, Ashok, masinter, Zakim, RRSAgent, jar, JeniT, plinss, DKA, noah, timbl, Norm, ht, darobin, plinss_, trackbot, Yves
- 14:58:08 [JeniT]
- mnot: we've had some discussions on this within IETF for the last year or so
- 14:58:51 [JeniT]
- ... Ned is doing a revision of [some RFC]
- 14:59:25 [JeniT]
- ... and revisions of link relations RFCs
- 14:59:34 [JeniT]
- ... and the message header registries RFCs
- 14:59:54 [JeniT]
- ... and another document to distil this discussion into "how to set up a registry"
- 15:00:16 [JeniT]
- masinter: I have done some work on that
- 15:00:28 [JeniT]
- mnot: there are things that IANA can do without updating RFCs
- 15:00:36 [JeniT]
- jar: are they cooperative?
- 15:00:51 [masinter]
- in http://www.w3.org/2001/tag/2011/12/evolution/Registries.html
- 15:00:52 [JeniT]
- mnot: yes, they need the IETF to take the initiative and they are resource constrained
- 15:01:02 [JeniT]
- ... and we've talked about having Wiki pages for each entry
- 15:01:26 [JeniT]
- ... this is a long term project
- 15:01:48 [JeniT]
- ... the mailing list is the main contact place
- 15:01:58 [JeniT]
- ... I am the main contact
- 15:02:09 [JeniT]
- masinter: a little W3C resource would make things go a lot faster
- 15:02:22 [Yves]
- https://www.ietf.org/mail-archive/web/happiana/current/maillist.html
- 15:02:37 [noah]
- https://www.ietf.org/mailman/listinfo/happiana
- 15:03:05 [JeniT]
- timbl: is anyone within the TAG following it?
- 15:03:13 [JeniT]
- yves: I am on the mailing list
- 15:03:17 [JeniT]
- masinter: I am as well
- 15:03:31 [JeniT]
- noah: I'm assuming Larry is our point person on this
- 15:03:54 [JeniT]
- masinter: I need help
- 15:04:19 [JeniT]
- ... I haven't been able to write this up in a way that was understood
- 15:04:38 [JeniT]
- ... we need some resources to make some things happen
- 15:04:51 [JeniT]
- ... and I don't know how to actually make this happen
- 15:06:05 [JeniT]
- noah: what aspects of this should be done within the TAG?
- 15:06:17 [JeniT]
- ... perhaps we could just free up some of Larry's time to work on it?
- 15:06:32 [JeniT]
- mnot: we would appreciate your review of what we have written up on the wiki
- 15:07:04 [JeniT]
- noah: so we should have one or two TAG members review it and frame a way forward
- 15:07:27 [JeniT]
- timbl: we can register our enthusiasm and encouragement
- 15:07:44 [masinter]
- the main problem i see is that current and previous TAG findings might be in conflict with the new directions being pursued, and that the TAG is more of a bottleneck than a group that can help.
- 15:07:51 [JeniT]
- ... on TAG ground, each registry is a piece of the architecture of the web
- 15:08:16 [JeniT]
- ... the TAG could dive into how much damage there is when someone makes a new URI scheme
- 15:08:38 [masinter]
- i prepared some material on this subject in the slides i put together for this meeting and was unable to get agenda time to present it
- 15:08:48 [JeniT]
- noah: arguably it's not a registry discussion
- 15:09:06 [JeniT]
- timbl: for a given registry, the TAG might want to point out the damage done by a badly designed scheme
- 15:09:23 [JeniT]
- mnot: so long as that doesn't prevent entries going into the registry
- 15:09:35 [JeniT]
- ... even if the bad ones are highlighted with blinking 'Evil' icons
- 15:10:55 [JeniT]
- noah: should we actually do this (about URI schemes)
- 15:11:27 [JeniT]
- ... is there any new work that we should kick off now?
- 15:12:10 [JeniT]
- ... also, does it help to have a formal TAG resolution to support this work?
- 15:12:30 [JeniT]
- mnot: probably not now, I just wanted to socialise this with you
- 15:13:19 [JeniT]
- noah: we're very interested in this, and we have been looking at this in an ongoing way, and we will keep on doing so
- 15:26:22 [JeniT]
- Topic: Web protocols: HTTP Futures & SPDY (with Mark Nottingham)
- 15:26:59 [JeniT]
- JeniT has left #tagmem
- 15:27:38 [JeniT]
- JeniT has joined #tagmem
- 15:35:18 [plh]
- plh has left #tagmem
- 15:35:37 [JeniT]
- noah: a few months ago, it started to look as though SPDY was expanding beyond Google
- 15:35:48 [JeniT]
- ... we had a technical discussion at TPAC 2011
- 15:36:23 [JeniT]
- ... it looks like there could be major changes to the web due to innovations such as SPDY
- 15:36:57 [JeniT]
- ... doing everything through SSL
- 15:37:11 [JeniT]
- mnot: the SPDY guys have strong dislike for transparent protocols (?)
- 15:37:30 [JeniT]
- noah: and there's a privacy angle here
- 15:37:47 [JeniT]
- ... we haven't for a while looked at this level of web architecture
- 15:38:05 [JeniT]
- ... we want to decide if this is an area where the TAG needs to do serious work, what the goals are, who is going to do it
- 15:38:23 [JeniT]
- ... and top priority is to have discussion with Mark
- 15:38:52 [JeniT]
- ... we could look at Yves email http://lists.w3.org/Archives/Public/www-tag/2011Dec/0034.html
- 15:39:12 [JeniT]
- ... to which there were some responses
- 15:39:56 [JeniT]
- mnot: I would like to talk for 10 minutes and then have discussion
- 15:42:40 [DKA]
- scribenick: DKA
- 15:43:07 [DKA]
- scribenick: JeniT
- 15:43:30 [JeniT]
- mnot: we started HTTPbis about 4 years ago
- 15:44:04 [JeniT]
- ... the idea was to revise HTTP because we now had 10 years of implementation experience of RFC2616
- 15:44:21 [JeniT]
- ... there was a lot of knowledge locked up in people's heads that we wanted to get written down
- 15:44:36 [JeniT]
- ... with quite a tight charter
- 15:44:51 [JeniT]
- ... not a new version of HTTP, no extensions, just fixing the specs
- 15:45:12 [JeniT]
- ... we're almost done
- 15:45:36 [JeniT]
- ... we have about 11 design tickets open, many of those will be closed really soon
- 15:45:49 [JeniT]
- ... the editors are Yves, Roy Fielding and Julian Reschke
- 15:46:08 [JeniT]
- ... we wanted to make something solid for 10-20 years
- 15:46:22 [JeniT]
- ... meanwhile implementers have come up with SPDY, mostly for performance
- 15:46:37 [JeniT]
- ... addressing a number of issues with HTTP and its serialisation over TCP (?)
- 15:46:56 [JeniT]
- ... the Google guys have an implementation, both server and client
- 15:47:41 [JeniT]
- ... Patrick McManus has done implementation in Firefox, also HTTP pipelining
- 15:48:00 [JeniT]
- ... he's found it easier to do SPDY than HTTP pipelining
- 15:48:13 [JeniT]
- ... it should be in Firefox 11
- 15:48:24 [JeniT]
- timbl: so it hasn't actually gone to market
- 15:48:36 [JeniT]
- yves: Opera also provided feedback on pipelining
- 15:48:51 [JeniT]
- mnot: the main problem with pipelining is that you have to use a lot of heuristics about when you can use pipelining
- 15:49:21 [JeniT]
- ... within pipelining, requests can block
- 15:49:32 [JeniT]
- noah: but in SPDY, you can interleave?
- 15:49:37 [JeniT]
- mnot: yes
- 15:49:49 [JeniT]
- ... Mike probably also covered Jim Getty's concerns about buffer bloat
- 15:50:13 [JeniT]
- ... I did an implementation of HTTP pipelining and SPDY in Python, and SPDY was much simpler
- 15:50:23 [JeniT]
- ... Amazon is using SPDY in the Kindle now, or are in process of doing so
- 15:50:44 [JeniT]
- ... Daniel Stenburg, behind curl, is implementing a C library for SPDY
- 15:51:17 [JeniT]
- noah: in Amazon Fire, there's the split browser, do they also use SPDY in requests out to the wider web?
- 15:51:22 [JeniT]
- mnot: I'm not sure
- 15:51:30 [JeniT]
- ... Google is practically the only server implementation
- 15:51:38 [JeniT]
- ... GenX has just announced implementation too
- 15:51:47 [JeniT]
- ... I noticed this momentum a couple of months ago
- 15:51:53 [JeniT]
- ... it's not just Google any more
- 15:52:19 [JeniT]
- ... I've had a lot of private discussions with various people, and everyone is very very interested in tracking/implementing this stuff
- 15:52:26 [JeniT]
- ... the market is choosing with its feet
- 15:53:00 [JeniT]
- ... the question is whether this gets done within a standards organisation, with interactions with other implementers than Google
- 15:53:14 [JeniT]
- ... it seems like it's necessary to take this work on
- 15:53:46 [JeniT]
- noah: we asked Mike how he felt about that, and he seemed to be keen on standardisation
- 15:54:09 [JeniT]
- mnot: we've had an ongoing discussion about standardisation
- 15:54:14 [JeniT]
- ... the team understands it will involve
- 15:54:26 [JeniT]
- ... there's a tension between getting to market and for everyone else to have their concerns met
- 15:54:49 [JeniT]
- ... I've been talking to people about this and putting together a proposed charter for this work
- 15:55:01 [JeniT]
- ... HTTPbis is just finishing up, and I don't want to distract from that
- 15:55:16 [JeniT]
- ... but time is important for the SPDY guys too
- 15:55:17 [timbl]
- q+ to ask about the extensibility point of HTTP headers in SPDY
- 15:56:08 [JeniT]
- ... I've been talking about rechartering the HTTPbis group to work on HTTP evolution
- 15:56:22 [JeniT]
- ... perhaps not saying that we should start from SPDY
- 15:56:45 [JeniT]
- ... Roy has been working on WOCCA (?)
- 15:56:56 [JeniT]
- ... but it's not been made public
- 15:57:38 [JeniT]
- ... looking at that and SPDY, I think they are conceptually very close
- 15:57:53 [Yves]
- s/WOCCA/WAKA
- 15:58:21 [JeniT]
- ... continuing the HTTP 1.1 revision
- 15:58:33 [JeniT]
- ... we have split up HTTPbis into components
- 15:58:56 [JeniT]
- ... SPDY only requires changes in one of those components
- 15:59:04 [JeniT]
- ... Part 1 of HTTPbis
- 15:59:15 [JeniT]
- timbl: what's SPDY's relationship to HTTP headers
- 15:59:27 [JeniT]
- mnot: it compresses them, but it uses the HTTP headers
- 15:59:45 [JeniT]
- ... there are some headers that aren't needed in SPDY
- 16:00:17 [JeniT]
- ... I used the same API as for HTTP when I did SPDY implementation
- 16:00:29 [JeniT]
- ... there might be other tweaks, but SPDY would be a superset
- 16:01:06 [JeniT]
- noah: SPDY would multiplex on one connection rather than having multiple connections
- 16:01:21 [JeniT]
- timbl: people have assumed HTTP would be replaced in the future
- 16:01:29 [JeniT]
- ... and therefore HTTP URIs would be replaced by other things
- 16:02:00 [JeniT]
- ... but the HTTP namespace can be persistent even if the protocol works
- 16:02:13 [JeniT]
- ... calling it HTTP 2 might be useful to avoid that confusion
- 16:02:32 [JeniT]
- mnot: questions about spdy: URIs have always been resisted
- 16:02:47 [JeniT]
- noah: there's an interaction with HTTPS and TLS and certificates
- 16:03:13 [JeniT]
- ... there are differences between http: and https: URIs, https: uses certificates and http: don't
- 16:03:38 [JeniT]
- mnot: there's a set of issues around TLS, about whether the CAs are a good source of truth
- 16:03:56 [JeniT]
- noah: how far has the discussion gone?
- 16:04:19 [JeniT]
- mnot: core people in SPDY feel that using TLS by default would improve the web
- 16:04:29 [JeniT]
- ... other people don't agree
- 16:04:50 [JeniT]
- noah: there are a bunch of issues with TLS, one of which is to do with name resolution
- 16:05:13 [JeniT]
- ... it means I have to get a certificate for my server
- 16:05:32 [JeniT]
- mnot: right now SPDY says you will deploy over TLS
- 16:05:57 [JeniT]
- timbl: what about certificates from DNS Sec?
- 16:06:07 [JeniT]
- mnot: there's a bunch of work on that, yes
- 16:06:19 [JeniT]
- ... which sometimes gets governments involved
- 16:06:27 [JeniT]
- ... the question is whether we can leverage it in time for SPDY
- 16:06:53 [JeniT]
- ... in the IETF people are uncomfortable with the 'S' in 'HTTPS'
- 16:07:08 [JeniT]
- ... that there shouldn't be a flag in the URI that indicates security
- 16:07:13 [JeniT]
- ... but the browser people like it
- 16:07:51 [JeniT]
- ... the concept of the origin server means having 'S' is really useful
- 16:08:04 [JeniT]
- timbl: but you may want to add more constraints, not just the 'S' bit
- 16:08:16 [JeniT]
- mnot: the question is about whether you should have it in the identifier
- 16:08:27 [JeniT]
- timbl: in RDF it's a real pain
- 16:08:47 [JeniT]
- ... moving to HTTPS wreaks havoc with links
- 16:09:01 [JeniT]
- ... I've wondered about using POWDER to put a label on the home page
- 16:09:16 [JeniT]
- ... to say that anything that starts 'https' should have the same identity as if you had 'http'
- 16:09:26 [JeniT]
- ... like a canonical link
- 16:09:42 [JeniT]
- mnot: I have a format for describing canonical URIs for a domain
- 16:09:53 [JeniT]
- ... but this is a real tangent
- 16:10:38 [JeniT]
- plinss: my understanding is that TLS and SPDY are orthogonal
- 16:10:59 [JeniT]
- mnot: the way it's currently defined, TLS and SPDY are bundled
- 16:11:09 [JeniT]
- ... I think there are cases where you don't want to use it
- 16:11:21 [JeniT]
- masinter: if you start with a HTTP URL, does it use SPDY?
- 16:11:36 [JeniT]
- mnot: it will upgrade the connection
- 16:12:00 [JeniT]
- ... for an HTTPS URI, there's another negotiation
- 16:12:16 [JeniT]
- noah: Google is using SPDY by default for HTTPS URIs
- 16:12:48 [JeniT]
- mnot: using NPN is an uncontroversial use
- 16:12:57 [JeniT]
- ... OpenSSL isn't going to support it until the next version
- 16:13:08 [JeniT]
- noah: how does this affect CDNs such as Akamai?
- 16:13:09 [Yves]
- s/NPN/TLS NPN/
- 16:13:17 [JeniT]
- mnot: they will need to support it
- 16:13:36 [JeniT]
- ... it used to be hard because you need an IP per certificate
- 16:13:46 [JeniT]
- ... now there's SSNI (?) but it's not perfectly deployed
- 16:14:03 [JeniT]
- ... which is the Host header for TLS
- 16:14:03 [Yves]
- s/SSNI/TLS SNI extension/
- 16:14:22 [JeniT]
- ... so that you can have 100 hostnames on one IP address
- 16:14:51 [JeniT]
- noah: how does the HTTPS work through something like Akamai?
- 16:15:00 [JeniT]
- mnot: they will need to know your private key or generate one for you
- 16:15:16 [JeniT]
- ... one of the metrics of a tracker is rapid changing of certificates
- 16:15:32 [JeniT]
- ... back to the charter
- 16:15:47 [JeniT]
- ... the new bit is working on HTTP 2.0 with the goal of improving performance
- 16:15:52 [JeniT]
- ... more efficient use of network resources
- 16:16:05 [JeniT]
- ... deployment on today's internet, using IPv4 and IPv6
- 16:16:17 [JeniT]
- ... maintaining ease of deployment
- 16:16:35 [JeniT]
- ... and balancing that with reflecting modern security requirements
- 16:16:58 [JeniT]
- ... there's a new requirement in IETF, any protocol has to have "mandatory to implement security"
- 16:17:14 [JeniT]
- ... it has to have an adequate security mechanism that implementations must support
- 16:17:54 [JeniT]
- ... the idea is to recharter the working group
- 16:18:04 [JeniT]
- ... starting work around end of March
- 16:18:15 [JeniT]
- ... which means HTTPbis needs to have been substantially done by then
- 16:19:27 [JeniT]
- ... I'm hoping the HTTPbis review will be fairly straightforward
- 16:19:34 [JeniT]
- ... because it's already gone through so much review
- 16:19:57 [JeniT]
- ... particularly because we're not introducing new things
- 16:20:23 [JeniT]
- ... we would put out a call for proposals for a starting point, one of which will be SPDY
- 16:20:35 [JeniT]
- ... there's a lot of running code out there for SPDY
- 16:21:15 [JeniT]
- ... the obvious question is why recharter the HTTP WG to do this, rather than creating a new one?
- 16:21:32 [JeniT]
- ... I think it's worthwhile because we have a good working pattern and an established community
- 16:21:53 [JeniT]
- ... we've talked about Mike Belshy and Julian Reschke being editors on the spec
- 16:22:05 [Yves]
- s/Belshy/Belshe/
- 16:22:20 [JeniT]
- timbl: the WG might have to be warned about being open to new people
- 16:22:32 [JeniT]
- mnot: we have almost complete coverage of HTTP implementers
- 16:22:40 [JeniT]
- ... this needs to be a worthy replacement for HTTP 1.1
- 16:22:58 [JeniT]
- ... we've got firewall, client, library, intermediary, embedded guys
- 16:23:10 [JeniT]
- ... if I can't get it through, we'll charter a separate WG
- 16:23:43 [JeniT]
- ... this is obviously of interest and importance to the TAG
- 16:24:01 [JeniT]
- DKA: in naming it HTTP 2.0, isn't there a danger that the scope gets expanded?
- 16:24:12 [JeniT]
- mnot: yes, we've dealt with that in HTTPbis
- 16:24:29 [JeniT]
- ... and the charter is written in a focused way
- 16:24:35 [JeniT]
- ... to prevent that
- 16:24:52 [masinter]
- masinter has joined #tagmem
- 16:24:56 [masinter]
- http://masinter.blogspot.com/2011/12/http-status-cat-418-i-teapot.html
- 16:25:19 [DKA]
- ScribeNick: DKA
- 16:25:20 [mnot]
- mnot has joined #tagmem
- 16:26:01 [DKA]
- tim: looks good....
- 16:26:12 [DKA]
- s/tim/timbl/
- 16:26:25 [DKA]
- … I think it's good to bring it out under a http 2.0 banner -
- 16:26:34 [noah]
- q?
- 16:26:36 [noah]
- ack next
- 16:26:38 [Zakim]
- timbl, you wanted to ask about the extensibility point of HTTP headers in SPDY
- 16:27:16 [DKA]
- … I think the fine line between directly taking on board existing work and allowing people to make arbitrary changes to existing work that runs is one I understand...
- 16:27:17 [JeniT]
- ScribeNick: JeniT
- 16:27:34 [JeniT]
- jar: Jim Gettys gave us a presentation on buffer bloat, and I wondered how this related
- 16:27:39 [JeniT]
- ... is this radical enough?
- 16:28:30 [JeniT]
- ... he was talking about self-authenticating content and things
- 16:28:46 [JeniT]
- mnot: this enables a solution to buffer bloat
- 16:28:52 [JeniT]
- ... it will use TCP better
- 16:29:07 [JeniT]
- ... particularly when people pull content back onto single domains rather than sharding
- 16:29:33 [JeniT]
- ... right now the interest is in maintaining the client/server model
- 16:30:02 [JeniT]
- noah: I think Jim spoke sympathetically about SPDY
- 16:31:06 [JeniT]
- timbl: back to the HTTP level, I've been trying to push rather than a content-addressable system, you might be able to go back to the referer of a link to get information
- 16:31:15 [masinter]
- there's a possibility that the two go together: SPDY for interactive, dynamic, personal, private traffic, and content addressible networking for public, cachable, distributed content.
- 16:31:28 [JeniT]
- ... for example, to bootstrap into a peer-to-peer system
- 16:31:34 [JeniT]
- mnot: have you seen Metalink?
- 16:31:48 [JeniT]
- ... a new link relation called 'duplicate'
- 16:32:01 [DKA]
- rfc5854
- 16:32:10 [JeniT]
- ... an exact byte-for-byte duplicate for a given representation
- 16:32:17 [masinter]
- http://tools.ietf.org/html/rfc5854
- 16:32:41 [JeniT]
- timbl: the idea is to cache everything you link to to two levels
- 16:32:54 [JeniT]
- mnot: there's a lot of interesting things to do in caching
- 16:33:10 [JeniT]
- ... the quality of cache implementations is something that bothers me
- 16:33:18 [masinter]
- pursuing both simultaneously would mean you wouldn't have to rely on caching
- 16:33:26 [JeniT]
- ... I'm concerned around the parallel tracks of caching, for example with AppCache
- 16:33:47 [JeniT]
- timbl: caches tend to be temporary; this idea is a mutual-aid system
- 16:34:17 [masinter]
- wonder if some of hte weaker parts of HTTP could be left behind
- 16:34:22 [JeniT]
- ... you'd build it into Apache and the client, and you'd be able to get data from parts of the network that were cut off
- 16:34:46 [JeniT]
- masinter: there's lots of HTTP that isn't very good, that you could leave behind if you're not encapsulating all of HTTP
- 16:34:55 [JeniT]
- ... and others that you could promote
- 16:35:09 [JeniT]
- ... for example caching based on time stamps vs on ETags
- 16:35:32 [JeniT]
- ... also HTTP uses the same transport for dynamic, private, interactive content as for large, public, static content
- 16:36:09 [JeniT]
- ... right now we use Vary headers to distinguish between them
- 16:36:21 [JeniT]
- ... maybe there's some other way that would be more reliable
- 16:36:45 [JeniT]
- mnot: I'm nervous about that, because how far do you go? we don't want two separate protocols really
- 16:37:00 [JeniT]
- masinter: you only split things off when they really don't fit
- 16:37:05 [JeniT]
- mnot: I'm not convinced they don't fit
- 16:37:21 [JeniT]
- noah: you can use a new URI scheme, that requires an early commitment
- 16:37:41 [DKA]
- q+
- 16:38:18 [JeniT]
- DKA: do you know of any mobile implementations of SPDY?
- 16:38:42 [JeniT]
- mnot: I don't know of any, but it looks like a tempting target for mobile, because the connection is used more efficiently
- 16:39:06 [JeniT]
- ... it looks like a real win, and you can use SPDY in the proxy
- 16:39:15 [JeniT]
- noah: what about battery drain on doing encryption?
- 16:39:17 [masinter]
- look at SPDY android
- 16:39:32 [JeniT]
- mnot: people claim TLS is not that hard; it depends on cipher strength
- 16:39:42 [JeniT]
- ... I consider TLS and wire protocols to be separate
- 16:40:00 [JeniT]
- DKA: the major battery drain aside from the display is usually the radio
- 16:40:36 [DKA]
- q-
- 16:41:20 [JeniT]
- noah: I propose that this is put on the alert list for Jeff
- 16:41:42 [JeniT]
- ... it sounds as if the right people are working on this in the IETF, but I can't see that we need to parachute in
- 16:42:00 [JeniT]
- ... I think we should have a contact point in the TAG, and monitor progress
- 16:42:30 [JeniT]
- mnot: I would add that this is likely to be discussed at Paris in late March
- 16:43:21 [JeniT]
- noah: Yves, you've traditionally had actions on this
- 16:43:39 [JeniT]
- yves: I will follow this for W3C anyway
- 16:44:12 [noah]
- close ACTION-640?
- 16:44:42 [noah]
- close ACTION-640
- 16:44:42 [trackbot]
- ACTION-640 Frame F2F discussion of SPDY/HTTP futures closed
- 16:45:05 [JeniT]
- yves: my email also touched on WebSocket
- 16:45:13 [JeniT]
- ... most of the communication on that won't use URIs
- 16:48:14 [noah]
- ACTION: Yves to prepare telcon discussion of protocol-related issues, e.g. Websockets/hybi (but not SPDY)Due: 2012-02-21
- 16:48:14 [trackbot]
- Created ACTION-658 - Prepare telcon discussion of protocol-related issues, e.g. Websockets/hybi (but not SPDY)Due: 2012-02-21 [on Yves Lafon - due 2012-01-13].
- 16:49:54 [noah]
- ACTION: Yves to track IETF efforts on HTTP 2.0 & SPDY Due: 2012-03-20
- 16:49:55 [trackbot]
- Created ACTION-659 - Track IETF efforts on HTTP 2.0 & SPDY Due: 2012-03-20 [on Yves Lafon - due 2012-01-13].
- 16:53:41 [JeniT]
- noah: we need to talk about things for Jeff
- 16:53:56 [mnot]
- https://datatracker.ietf.org/wg/dane/charter/
- 16:54:53 [JeniT]
- ... CA system
- 16:55:05 [JeniT]
- ... perhaps other security aspects
- 16:55:13 [JeniT]
- ... perhaps how to deal with the TAG issues
- 16:55:16 [JeniT]
- ... action item review
- 16:55:39 [JeniT]
- Topic: Redirect headers
- 16:55:41 [masinter]
- you might want to also look at the long list of dead TAG findings
- 16:55:47 [JeniT]
- Topic: Redirection semantics
- 16:55:57 [masinter]
- http://www.w3.org/2001/tag/findings
- 16:56:04 [JeniT]
- mnot: issue with fragment identifiers and redirections
- 16:56:09 [masinter]
- and also "Approved findings" we no longer believe in
- 16:56:15 [JeniT]
- ... HTTP doesn't say which one gets precedence
- 16:56:39 [JeniT]
- ... we talked with you and at the time we said, 'there's not good interop here'
- 16:56:48 [JeniT]
- ... so didn't say what to do
- 16:57:02 [JeniT]
- ... we didn't cover when the request has a fragid and the redirect location doesn't
- 16:57:09 [JeniT]
- ... since then, we've tested implementations
- 16:57:17 [JeniT]
- ... and there is good interop
- 16:58:11 [JeniT]
- ... from a webarch standpoint would the TAG be concerned if the combination of fragid and redirect were determined by HTTP rather than media type dependent?
- 16:58:27 [JeniT]
- noah: ht might have input on this
- 16:58:44 [JeniT]
- mnot: we need an answer soon because we want it in HTTPbis
- 16:59:17 [JeniT]
- ... my opinion is that from an implementation standpoint it is bad to make it media type dependent
- 16:59:22 [noah]
- noah: would it be convenient for you to send an e-mail asking the TAG to consider this question? If so, i'll use that to trigger telcon discussion.
- 16:59:35 [noah]
- mnot: Fine, no problem, I'll send the note.
- 16:59:54 [JeniT]
- ... making it the same for everything is significantly less complex
- 17:00:19 [noah]
- Recent TAG finding on fragment identifiers in Web Applications http://www.w3.org/2001/tag/doc/IdentifyingApplicationState
- 17:00:23 [JeniT]
- timbl: this is deeply connected with how the Semantic Web / Linked Data worked
- 17:00:37 [JeniT]
- ... to me it was a shock that you could redirect to something with a fragid in it
- 17:00:57 [JeniT]
- ... how common is it to have that kind of redirection?
- 17:01:04 [JeniT]
- jar: Dublin Core
- 17:01:36 [mnot]
- HTTPbis bug: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295
- 17:01:41 [JeniT]
- plinss: I think this is going to become more common as you have fragments on video/audio
- 17:01:48 [JeniT]
- jar: URL shorteners
- 17:02:03 [JeniT]
- timbl: do you have RDF test cases?
- 17:02:08 [JeniT]
- mnot: no
- 17:02:23 [JeniT]
- ... there's strong interop amongst the implementations we've checked
- 17:03:05 [JeniT]
- timbl: adding the fragid to the redirected URI isn't a problem
- 17:03:08 [JeniT]
- jar: +1
- 17:03:21 [JeniT]
- ... I think it's implied by RFC3986
- 17:03:45 [JeniT]
- masinter: one way or the other it has to be made explicit
- 17:03:58 [JeniT]
- mnot: I'll send noah an email and we'll take it forward
- 17:04:10 [JeniT]
- jar: I weighed in on this before and didn't get any reaction
- 17:04:25 [masinter`]
- masinter` has joined #tagmem
- 17:05:13 [noah]
- http://www.w3.org/2001/tag/doc/IdentifyingApplicationState
- 17:05:14 [JeniT]
- noah: the TAG did quite a bit of work in the last year on web application state and fragid semantics
- 17:05:23 [JeniT]
- ... that might be of interest
- 17:05:40 [mnot]
- http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238
- 17:05:52 [JeniT]
- Topic: Redirection of POST and User Intervention
- 17:06:09 [JeniT]
- mnot: most of the browsers redirect automatically
- 17:06:20 [JeniT]
- ... because the users don't know whether it's safe to redirect across domains
- 17:06:34 [JeniT]
- ... so perhaps we should remove that requirement from HTTP
- 17:06:50 [JeniT]
- ... but it's a fairly big change
- 17:07:02 [JeniT]
- ... but it doesn't reflect reality
- 17:07:09 [JeniT]
- timbl: has anyone suggested any improvement?
- 17:07:23 [JeniT]
- ... currently this is a fairly huge hole
- 17:07:37 [JeniT]
- mnot: there are so many ways to generate requests to multiple hosts in browsers
- 17:07:50 [JeniT]
- ... they are moving away from making security visible
- 17:07:58 [JeniT]
- ... because it doesn't meaningfully improve security
- 17:08:23 [JeniT]
- timbl: so it's a cross-domain issue?
- 17:08:48 [JeniT]
- mnot: we could phrase the requirement be about cross-domain redirects
- 17:08:49 [jar]
- n.b. the discussion is of 301 redirects specifically (with unsafe methods such as POST)
- 17:09:06 [JeniT]
- ... we can't make incompatible changes in HTTPbis unless it's a serious security issue
- 17:09:09 [JeniT]
- ... and this isn't serious
- 17:09:23 [JeniT]
- ... right now this applies same-domain
- 17:09:36 [JeniT]
- timbl: relaxing it for same-origin makes sense
- 17:09:47 [JeniT]
- mnot: one browser prompts in a couple of specific situations
- 17:09:54 [JeniT]
- ... but most already ignore the requirement
- 17:10:11 [JeniT]
- Topic: Identifier Overloading
- 17:10:21 [JeniT]
- mnot: Sec- prefix on HTTP headers
- 17:10:36 [JeniT]
- ... adding semantics to an identifier brings problems
- 17:10:41 [JeniT]
- ... how do you add more prefixes?
- 17:10:59 [JeniT]
- ... X- for experimental, then it gets adopted
- 17:11:10 [JeniT]
- ... (that is close to deprecated)
- 17:11:54 [JeniT]
- noah: how you support decentralised extensibility + smooth evolution from experimental to common is something the TAG could look at
- 17:12:13 [JeniT]
- ... I'm not sure we can do that well in the TAG
- 17:12:22 [JeniT]
- mnot: we're covering it a bit in happiana
- 17:13:00 [JeniT]
- jar: registries, decentralised extensibility and persistent naming are all closely related
- 17:13:12 [JeniT]
- noah: it's more about whether the community can see progress
- 17:13:33 [JeniT]
- (wrapup)
- 17:14:58 [plinss]
- <br type='lunch' duration='75min'>
- 18:10:07 [DKA]
- DKA has joined #tagmem
- 18:35:41 [masinter]
- masinter has joined #tagmem
- 18:35:49 [DKA]
- Scribe: Dan
- 18:35:53 [DKA]
- ScribeNick: DKA
- 18:36:59 [DKA]
- Minutes integration: Wednesday : Dan ; Thursday: JAR ; Friday : Dan
- 18:37:34 [DKA]
- s/Wednesday \: Dan/Wednesday \:Yves/
- 18:38:55 [JeniT]
- "we need to talk about things for Jeff
- 18:38:57 [JeniT]
- CA system
- 18:38:58 [JeniT]
- perhaps other security aspects
- 18:39:00 [JeniT]
- perhaps how to deal with the TAG issues
- 18:39:01 [JeniT]
- action item review"
- 18:39:01 [trackbot]
- Sorry, couldn't find user - item
- 18:39:25 [DKA]
- Topic: Stuff for Jeff
- 18:39:58 [DKA]
- Noah: Jeff has asked the TAG to alert him to big controversies and threats to the Web that he might not know about.
- 18:40:10 [DKA]
- … I have ACTION-568.
- 18:40:13 [noah]
- ACTION-568?
- 18:40:13 [trackbot]
- ACTION-568 -- Noah Mendelsohn to draft note for Jeff Jaffe listing 5 top TAG priorities as trackable items. -- due 2012-01-03 -- OPEN
- 18:40:13 [trackbot]
- http://www.w3.org/2001/tag/group/track/actions/568
- 18:40:16 [DKA]
- … We are overdue on this action.
- 18:40:29 [DKA]
- … We need a plan that will close in a few days for an initial note to Jeff.
- 18:40:42 [DKA]
- … This says "5" but I don't think 5 is a magic number.
- 18:40:46 [DKA]
- Yves: 20 items is too many.
- 18:40:53 [DKA]
- Noah: Let's see what we have.
- 18:41:06 [Yves]
- https://lists.w3.org/Archives/Member/tag/2012Jan/0001.html
- 18:41:44 [DKA]
- Noah: [outlines above list]
- 18:44:14 [DKA]
- [discussion on death of protocols]
- 18:44:47 [DKA]
- Yves: this is the list discussed during f2f in Edinburgh.
- 18:45:21 [DKA]
- Noah: two more - one is a think Dan asked for: should app cache vs app packaging be on the heads-up list for Jeff?
- 18:46:01 [DKA]
- … Noah: I think the only reason to highlight this is if it's not adequately highlighted in the workshop report.
- 18:46:50 [DKA]
- Dan: risk is more generally apps vs web.
- 18:46:57 [DKA]
- Jenit: which we already have.
- 18:47:16 [DKA]
- Ashok: [asks for clarification]
- 18:47:41 [DKA]
- Noah: We need descriptions of threats or potential threads to send to Jeff - between a paragraph and a short page.
- 18:50:39 [DKA]
- Noah: if people like the list, let's look at each one.
- 18:51:54 [DKA]
- JeniT: should the registries and IANA stuff get moved into the bigger section?
- 18:52:14 [DKA]
- … especially rdfa vs html link relations.
- 18:52:22 [DKA]
- Yves: this is not new.
- 18:52:47 [DKA]
- … if there will be more issues based on this - e.g. registries being misused - then yes.
- 18:53:18 [DKA]
- Noah: If we think e.g. Happiana will rise into a key issue then we might raise it to Jeff.
- 18:53:44 [DKA]
- … we could make it an addendum to the main list.
- 18:54:16 [DKA]
- Yves: "there have been issues - there will probably be more issues - there is this work happening (IANA)"
- 18:54:33 [DKA]
- JAR: … and a small effort by w3c staff could help.
- 18:54:48 [DKA]
- Noah: Jeff asked me for [major issues] that might hit him.
- 18:55:18 [DKA]
- JeniT: Along those lines, the section on SPDY and http - this feels less like something that we need to be mega-concerned about.
- 18:56:03 [DKA]
- Noah: I think http is a major part of the Web - we should [outline the key topics] and then say "we have been working with e.g. mnot about it and this is what's happening..."
- 18:56:46 [DKA]
- Noah: let's go through the things Yves has drafted on each of these.
- 18:58:02 [DKA]
- Noah: first - "Specifications with the Same Scope…"
- 18:58:39 [DKA]
- Noah: Question I would ask - you talk about RDFa
- 18:59:16 [DKA]
- Yves: With the evolution of different stacks, they step on other technology stacks' feet. It's difficult to predict that.
- 18:59:26 [JeniT]
- q+ to talk about HTML.next
- 18:59:36 [DKA]
- Noah: If we know of anything similar to microdata/rdfa then we should alert Jeff.
- 18:59:56 [DKA]
- Yves: another one might be xpath and css selectors.
- 19:00:12 [DKA]
- Noah: is that resolving?
- 19:00:21 [DKA]
- Yves: I think it's more or less under control.
- 19:01:00 [DKA]
- JeniT: We can say - following discussion with plh over html.next there seem to be areas e.g. speech but our advice from him was that this wasn't going to cause problems.
- 19:01:15 [noah]
- I think we need to tell Jeff where the ones we know about stand, and where there are others that are likely to be problems. I hear Yves saying: microdata/RDFa and CSS/XPath are probably headed for resolution, but these things will keep happening.
- 19:01:19 [JeniT]
- q-
- 19:01:26 [DKA]
- … the two things that could be hot topics look like they are being handled in the right way.
- 19:01:42 [DKA]
- Noah: I think this should come out under my signature on behalf of the TAG.
- 19:01:57 [DKA]
- … I feel sufficiently informed on this one to take a cut.
- 19:02:26 [noah]
- Current draft: The TAG, as part of its review activity will continue to monitor such
- 19:02:26 [noah]
- issues.
- 19:02:30 [noah]
- Suggested: The TAG, as part of its review activity will continue to monitor such
- 19:02:30 [noah]
- issues.
- 19:02:33 [DKA]
- Yves: last para where I said TAG is reviewing what is going on - even if we don't know an issue that will happen in the next 6 months, in 2 months we might discover an issue.
- 19:02:41 [noah]
- issues and we will alert you to any that we think are of particular concern.
- 19:02:56 [DKA]
- Noah: Next one - "phone apps vs web apps"
- 19:03:01 [JeniT]
- ScribeNick: JeniT
- 19:03:29 [JeniT]
- yves: there are a range of issues here, and I'm not sure what the crux is
- 19:03:38 [noah]
- YL: On the mobile, I'm not sure where the issues are.
- 19:03:41 [JeniT]
- DKA: there's things like URI schemes as well
- 19:03:50 [noah]
- DKA: It touches on things like vendor-specific URIs
- 19:05:52 [JeniT]
- ... and the "death of the web"
- 19:06:02 [JeniT]
- noah: can you send me an email?
- 19:06:14 [noah]
- ACTION: Dan to put together a bulleted list of items to go into this category
- 19:06:14 [trackbot]
- Sorry, couldn't find user - Dan
- 19:06:25 [JeniT]
- DKA: give me an action to include APIs, packaging, offline use, tools, monetisation
- 19:06:47 [JeniT]
- noah: if you could just draft a section?
- 19:07:14 [JeniT]
- DKA: ok
- 19:07:44 [JeniT]
- JeniT: do Facebook apps have similar characteristics?
- 19:08:17 [JeniT]
- DKA: the risk on mobile is apps running outside the browser, that could be done in the browser
- 19:08:23 [JeniT]
- ... due to artificial constraints
- 19:08:37 [JeniT]
- noah: widgets could run outside the browser, are they bad too?
- 19:08:52 [JeniT]
- DKA: this is where it's a grey area, because some people don't think Widgets are the Web
- 19:09:00 [JeniT]
- ... because they don't have addressability, for example
- 19:09:28 [JeniT]
- noah: outside the browser, forward/back navigation doesn't work
- 19:09:54 [JeniT]
- Ashok: are you thinking of Apps like iPad Apps?
- 19:10:12 [JeniT]
- DKA: it's definitely not just on the mobile phone, but this whole class of device
- 19:10:23 [JeniT]
- ... which uses the AppStore model
- 19:10:30 [JeniT]
- ... which diminishes the importance of the web
- 19:11:14 [JeniT]
- ... there are plenty of Apps that use web technologies
- 19:11:29 [JeniT]
- ... but you can't use the web to download them, rate them, talk about them etc
- 19:12:01 [JeniT]
- noah: I don't care about how I got the App but how you navigate out of the App
- 19:12:10 [JeniT]
- yves: so what about the Chrome Apps?
- 19:12:22 [JeniT]
- ... they are using web technologies
- 19:12:43 [JeniT]
- noah: if they're not linking to things on the web, then that's not so good
- 19:12:52 [JeniT]
- yves: the threat is the creation of a walled garden
- 19:13:02 [JeniT]
- Ashok: +1
- 19:13:19 [JeniT]
- DKA: so Chrome apps run in the browser, but you can only download them and use them in Chrome
- 19:13:39 [JeniT]
- noah: should we start each section with 'Threat:'
- 19:14:03 [JeniT]
- DKA: I think that's good: the threat is the browser is no longer the way that people find and download information
- 19:14:24 [JeniT]
- noah: I'm want to focus on the risk/threat for Jeff
- 19:15:10 [JeniT]
- DKA: the death of the browser as the mechanism for accessing information is the threat here
- 19:15:30 [JeniT]
- Ashok: in the browser, you can go to a different web page, and from an App you can't
- 19:15:42 [JeniT]
- noah: many Apps do it, but they break
- 19:16:07 [JeniT]
- Ashok: this is a way to try to earn money
- 19:16:23 [JeniT]
- ... to package something that you can then charge for
- 19:16:51 [JeniT]
- yves: not only for paying, but for editorial control: you can censor things
- 19:18:27 [JeniT]
- DKA: why should you care? because you won't be able to see information that isn't approved
- 19:18:35 [JeniT]
- ... on the web I can find other points of view
- 19:18:56 [JeniT]
- noah: most of this is stuff Jeff will be aware of
- 19:19:10 [JeniT]
- ... perhaps we want to say that he should be more worried about losing this war
- 19:19:37 [JeniT]
- DKA: there are other things about debunking claims such as not being able to charge for things
- 19:19:42 [JeniT]
- ... or accessing location
- 19:19:47 [JeniT]
- ... or accessing the camera
- 19:20:09 [JeniT]
- noah: in my experience geolocation doesn't work as well in the browser as in an App
- 19:20:26 [JeniT]
- DKA: the macro-issue is the other functions that the web can't do that Apps can
- 19:22:30 [JeniT]
- noah: vendors that support Apps may limit the ability of the browsers to perform as well as the Apps do
- 19:23:01 [JeniT]
- ... Apps have more complete access to the platform
- 19:23:10 [JeniT]
- ... they lose flexible linking to other web pages
- 19:23:31 [JeniT]
- ... the threat is that this remains attractive: the web hasn't blown these things away
- 19:24:14 [JeniT]
- Ashok: if APIs on the phone are really that much better than the APIs from the browser, that's a cause for concern
- 19:24:37 [JeniT]
- DKA: this is a complex area; highlighting some stuff on the technical level would be a good idea
- 19:24:42 [JeniT]
- ... let me draft something for Jeff
- 19:25:08 [JeniT]
- ... to give him some ammunition
- 19:25:21 [DKA]
- ScribeNick: DKA
- 19:25:24 [DKA]
- Noah: CAs
- 19:25:26 [masinter`]
- masinter` has joined #tagmem
- 19:26:05 [DKA]
- Yves: we should note that there is work going on in IETF and other places to help...
- 19:26:32 [DKA]
- JAR: Jeff ought to be mobilising w3c to work on this issue. This is really important.
- 19:26:45 [DKA]
- Tim: do you mean the first response or designing a better system?
- 19:27:03 [DKA]
- JAR: I mean that it's not obvious where to go. We have some ideas...
- 19:27:24 [DKA]
- JAR: Issue is the trust structure...
- 19:28:04 [DKA]
- Larry: In some case, if we don't figure it out then things won't advance. But in this case if we don't figure it out then bad things will happen.
- 19:28:10 [DKA]
- Noah: I think we all agree.
- 19:28:45 [DKA]
- Noah: [wordsmithing the description]
- 19:29:31 [DKA]
- … I'd like to see a paragraph "the practical effect of this is that right now in certain countries users are being redirected to fraudulent or improper copies of web sites - and that there is no way to fix this in the immediate future."
- 19:29:34 [masinter`]
- the concern is that these attacks point out a weakness in the architecture, and not just an isolated incident
- 19:29:50 [DKA]
- Yves: not only redirecting - but people having the feeling that they have a secure channel - and are not being spied on.
- 19:30:23 [DKA]
- Noah: We should start with some brief war stories - Another example: we have seen man-in-the-middle attacks to spy on politically sensitive traffic...
- 19:30:27 [DKA]
- Yves: as in Tunisia.
- 19:30:54 [DKA]
- Noah: I think it's important to say: right now it's not obvious how the technology will be deployed to stop this from happening.
- 19:31:44 [DKA]
- Larry: There's a concern that this is an architectural flaw rather than a set of isolated events. I share this concern.
- 19:31:55 [DKA]
- Yves: I can redraft this.
- 19:33:22 [DKA]
- Yves: we might expand on what we mean by trust issues...
- 19:33:35 [DKA]
- Noah: As long as the key points are up front.
- 19:33:35 [masinter`]
- Mark gave us https://datatracker.ietf.org/wg/dane/charter/
- 19:33:45 [DKA]
- JeniT: can we move that up to the top of the list?
- 19:33:49 [DKA]
- Yves: I agree.
- 19:33:56 [DKA]
- … add "red flag here."
- 19:34:05 [DKA]
- Noah: Now - "SPDY and HTTP"
- 19:34:31 [DKA]
- Noah: The highlight here is - this is not a threat, this is something you should be aware of …
- 19:35:29 [DKA]
- Yves: there should be info at the bottom about the new efforts in this space - the IETF httpbis rechartering.
- 19:35:41 [DKA]
- Noah: I can redraft this based on what we heard from Mark Nottingham.
- 19:35:54 [DKA]
- Noah: now "Death of Protocols"
- 19:36:24 [DKA]
- Noah: Can someone offer an example of this?
- 19:37:01 [DKA]
- Yves: not many things are using web sockets in a way you could call a "protocol." You just wait for data to come in without having the framing of http...
- 19:37:18 [DKA]
- … I'm not aware of any widely deployed app using web sockets though. So it's a potential threat.
- 19:37:43 [DKA]
- JAR: What's written here sounds right.
- 19:37:54 [DKA]
- Noah: Can you give me an example?
- 19:38:12 [DKA]
- Yves: e.g. the way communication was done in the past before TCP…
- 19:38:31 [DKA]
- Noah: Why is that death of protocols rather than "death of standardised interoperable protocols."
- 19:38:58 [DKA]
- JAR: It's not the death of existing protocol. It's the death of the process by which people publish their protocols.
- 19:39:24 [DKA]
- Tim: It could be the birth of many protocols… Some of these may get standardised, some won't...
- 19:40:22 [DKA]
- JAR: The outcomes could be good. There were objections from within IETF - for where the locus of documentation is. The traditional IEFT way of doing things is to write a RFC, associated that with a port, etc… Locus of communication is in IEFT and with the community around that (e.g. those building firewalls, routers, etc…).
- 19:40:41 [DKA]
- … what people are bothered by is - even though innovation is supported - that it's disruptive.
- 19:41:21 [DKA]
- Tim: if you run over TCP then you can tai end-to-end without talking to people...
- 19:42:45 [DKA]
- Noah: We were in a world where code was hard to deploy - now when you go to a site and you want the weather, there's a chance the site will send you the javascript code at that moment to speak that protocol in order to get the weather. The code is mobile and hence the value of standard protocols is greatly diminished.
- 19:42:58 [masinter`]
- IETF and W3C have a role in management of protocols in insuring several kinds of policy-based criteria: internationalization, security, privacy, as well as the ability to manage the traffic in terms of ports, traffic shaping, firewalls, etc. If there's no need to ever do that review, how will those (apparent) community values be retained.
- 19:43:35 [masinter`]
- gopher and www were not started as standards
- 19:43:40 [masinter`]
- and gopher was never a standard
- 19:43:41 [DKA]
- Tim: issue Jonathan was raising - you used to take new protocols to the IETF. But as long as you use an existing underlying protocol then maybe you're safe now [for using these new protocols].
- 19:43:47 [DKA]
- JAR: I think this is complicated.
- 19:43:59 [masinter`]
- and tim deployed some software which i downloaded, installed, and modified, without any IETF involvement
- 19:44:48 [DKA]
- … having to do with what layers in the stack have information about the traffic. It used to be that routers were pretty simple. Modern routers at wire speed are looking at things like the URI of an http request and making decisions as the packet goes by...
- 19:45:03 [DKA]
- … so it's a question of the locus of intelligent.
- 19:45:32 [DKA]
- Larry: 20 years ago some guy at CERN wrote some code and I downloaded it. The Web was deployed before there were any standards.
- 19:46:02 [DKA]
- Noah: But tim didn't download a new copy of the browser every time [he visited a web page.]
- 19:46:53 [DKA]
- Larry: IETF and w3c have policy initiatives around security, privacy, monitoring, ports, firewalls, etc… if there's never any need to do protocol review or standardisation, how do we retain those "community goods."
- 19:47:05 [noah]
- Possible message to Jeff: "As dynamically downloaded JavaScript libraries are increasingly used to implement ad-hoc, problem-specific protocols to access data, the usage and value of Web technologies such as URIs and HTTP may be reduced."
- 19:47:17 [DKA]
- Tim: e.g. quality review.
- 19:47:27 [DKA]
- Yves: there's also the possible reuse of that protocol.
- 19:47:48 [jar]
- goes to the network as a commons
- 19:47:56 [DKA]
- … if you're building something that gets widely used, and you're using a protocol that's not published then people will have a hard time reusing, etc...
- 19:48:31 [DKA]
- Tim: I think it's better to come to Jeff with possible failure scenarios.
- 19:49:18 [DKA]
- … one failure mode : when you buy some home automation hardware, it comes with its own Web server and runs its own protocol between the client and the server and as a result you have vendor lock-in.
- 19:49:44 [noah]
- Possible message to Jeff: "As dynamically downloaded JavaScript libraries are increasingly used to implement ad-hoc, problem-specific protocols to access data, the usage and value of Web technologies such as URIs and HTTP may be reduced, and we run the risks that result from proprietary protocols. For example {insert Tim's example of home toaster controller here}."
- 19:49:56 [JeniT]
- DKA: why is that any different now from in the past?
- 19:50:06 [JeniT]
- Yves: the difference is it's done in the browser
- 19:50:15 [masinter`]
- you odn't avoid vendor-lockin by using HTTP and URIs
- 19:51:00 [DKA]
- Tim: 2nd scenario : the toaster protocol might run on UDP so it brings my home network down…
- 19:51:03 [Yves]
- it's not vendor lock-in, it's difficult upgrade path, no review on what can go wrong (security etc...)
- 19:51:30 [DKA]
- Tim: these are hidden protocols.
- 19:52:00 [masinter`]
- vendor lockin is completely irrelevant here
- 19:52:29 [DKA]
- Tim: What's breaking is the ability to construct things in a modular way.
- 19:52:44 [DKA]
- Noah: No this might be well structured but it's all very immediate.
- 19:52:48 [DKA]
- Tim: What am I missing?
- 19:53:22 [DKA]
- Noah: I'm saying the right model is - I'd like to use this on things that don't support javascript, I'd like to be able to implement it in multiple environments, etc...
- 19:53:53 [DKA]
- Tim: What you're trying to do is to combine multiple components...
- 19:53:59 [masinter`]
- for the things you're talking about, there's no difference between non-standard protocols and SOAP
- 19:54:05 [DKA]
- Noah: damage would be no freedom of choice in toasters.
- 19:54:15 [noah]
- TBL: Issues include vendor lockin, badly designed (no IETF review)
- 19:54:22 [DKA]
- Peter: This happens now...
- 19:54:31 [DKA]
- JAR: difference is it goes through firewalls...
- 19:54:53 [DKA]
- Peter: I think the main difference is that it's going to happen within the web browser [with Websockets].
- 19:55:17 [masinter`]
- between REST or SOAP vs. udp directly, what's really the difference, except that websockets doesn't incur the same overhead? And perhaps SPDY will make this concern moot.
- 19:55:31 [DKA]
- Tim: example of using libraries - standardisation will happen between people making the libraries.
- 19:56:09 [DKA]
- Peter: my fear is that people will use proprietary protocols so that makes it more difficult for others to re-use data across the Web.
- 19:56:40 [DKA]
- Larry: people have already been layering for decades proprietary protocols over http. Maybe this is actually not a problem.
- 19:56:50 [masinter`]
- at least a decade
- 19:57:13 [DKA]
- Noah: I'd like to take a look at where we stand. We're mostly there except on this one.
- 19:57:21 [DKA]
- …worth another 10-15 minutes?
- 19:57:29 [masinter`]
- i don't think we should raise to Jeff an issue if we can't articulate a problem
- 19:57:44 [DKA]
- JAR: What larry said.
- 19:57:53 [Yves]
- +1
- 19:58:00 [DKA]
- JeniT: Yes I agree we shouldn't raise it to Jeff if we can't articulate a problem.
- 19:58:03 [DKA]
- +1
- 19:58:33 [DKA]
- Noah: anyone who could offer something to discuss on a telecon.
- 19:58:52 [DKA]
- Noah: Ok - for the moment this will not be included in the note to jeff unless someone comes forward with a proposal on the text.
- 20:00:23 [DKA]
- Noah: ok - Yves to draft something on "overlapping specs"; Dan to do apps and web apps; Noah to do Certs (to be moved to top with red flag); Yves to do SPDY; Protocols is out unless someone comes out with text to discuss; all - please send me paragraphs and I will integrate them.
- 20:00:39 [DKA]
- ACTION: Dan to draft text on apps and webapps
- 20:00:39 [trackbot]
- Sorry, couldn't find user - Dan
- 20:00:51 [noah]
- ACTION: Noah to integrate input from DKA and Yves for note to Jeff, and draft section on CA Due: 2012-10-17
- 20:00:52 [trackbot]
- Created ACTION-660 - Integrate input from DKA and Yves for note to Jeff, and draft section on CA Due: 2012-10-17 [on Noah Mendelsohn - due 2012-01-13].
- 20:01:22 [noah]
- ACTION-660 Due 2012-01-17
- 20:01:23 [trackbot]
- ACTION-660 Integrate input from DKA and Yves for note to Jeff, and draft section on CA Due: 2012-10-17 due date now 2012-01-17
- 20:03:44 [DKA]
- [end of discussion on Jeff note]
- 20:03:52 [ht]
- ht has joined #tagmem
- 20:04:15 [noah]
- http://www.w3.org/2001/tag/group/track/actions/overdue
- 20:04:32 [DKA]
- ACTION-344?
- 20:04:32 [trackbot]
- ACTION-344 -- Jonathan Rees to alert TAG chair when CORS and/or UMP goes to LC to trigger security review -- due 2012-01-01 -- OPEN
- 20:04:32 [trackbot]
- http://www.w3.org/2001/tag/group/track/actions/344
- 20:06:09 [DKA]
- JAR: Answer has been "Ok - explain to users of the spec how to be careful."
- 20:06:58 [DKA]
- Topic: Action Item Review
- 20:07:06 [noah]
- ACTION-480?
- 20:07:06 [trackbot]
- ACTION-480 -- Daniel Appelquist to draft overview document framing Web applications as opposed to traditional Web of documents -- due 2011-07-05 -- OPEN
- 20:07:06 [trackbot]
- http://www.w3.org/2001/tag/group/track/actions/480
- 20:07:18 [noah]
- close ACTION-480
- 20:07:18 [trackbot]
- ACTION-480 Draft overview document framing Web applications as opposed to traditional Web of documents closed
- 20:09:04 [DKA]
- ACTION-601?
- 20:09:04 [trackbot]
- ACTION-601 -- Noah Mendelsohn to document in product pages wrapup of HTML5 last call work, leading to HTML next review -- due 2011-12-27 -- OPEN
- 20:09:04 [trackbot]
- http://www.w3.org/2001/tag/group/track/actions/601
- 20:09:13 [noah]
- action-601?
- 20:09:13 [trackbot]
- ACTION-601 -- Noah Mendelsohn to document in product pages wrapup of HTML5 last call work, leading to HTML next review -- due 2011-12-27 -- OPEN
- 20:09:13 [trackbot]
- http://www.w3.org/2001/tag/group/track/actions/601
- 20:09:14 [DKA]
- Noah: I believe I did this - can I close this action?
- 20:09:18 [noah]
- close ACTION-601
- 20:09:18 [trackbot]
- ACTION-601 Document in product pages wrapup of HTML5 last call work, leading to HTML next review closed
- 20:10:39 [noah]
- ACTION-645?
- 20:10:39 [trackbot]
- ACTION-645 -- Noah Mendelsohn to take off draft indication and put dates on URI Definition and Discovery Product page -- due 2011-12-29 -- OPEN
- 20:10:39 [trackbot]
- http://www.w3.org/2001/tag/group/track/actions/645
- 20:10:44 [noah]
- close ACTION-645
- 20:10:45 [trackbot]
- ACTION-645 Take off draft indication and put dates on URI Definition and Discovery Product page closed
- 20:16:17 [plinss]
- plinss has joined #tagmem
- 20:34:44 [DKA]
- Topic: CA Issue
- 20:35:21 [DKA]
- Noah: You could make a case this is a security problem that the TAG should be involved in in an ongoing way. Seems like a really important development to me. We should be involved.
- 20:35:30 [DKA]
- Ashok: It doesn't look like our's to tackle.
- 20:35:46 [DKA]
- JAR: Everyone should have awareness of, especially us.
- 20:36:05 [DKA]
- Noah: If we thought the Web was going to crumble then we should go to w3c membership and say that.
- 20:36:24 [DKA]
- JAR: at least 3 different solutions have been put forward and it's not clear [which is best].
- 20:36:48 [jar]
- https://www.youtube.com/watch?v=Z7Wl2FW2TcA I think
- 20:36:52 [DKA]
- JAR: e.g. "SSL and the future of authenticity"
- 20:37:01 [DKA]
- JAR: …and a third one.
- 20:38:07 [DKA]
- JeniT: is there anything useful we can say to people developing web applications with SSL about what they should or should not be doing...
- 20:38:18 [jar]
- https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-against-google
- 20:38:23 [DKA]
- Yves: i think it's more for users - that they should rely on more than just the ssl padlock...
- 20:38:52 [DKA]
- Noah: How urgent is this?
- 20:39:12 [DKA]
- Yves: If it's easy enough to divert DNS and create fake certificates...
- 20:39:23 [DKA]
- JAR: whole part of the video [above] is that it's very easy to do this.
- 20:40:08 [DKA]
- Yves: The first issue is that users should know that even if they think it's safe it might not be safe… E.g. in some countries even if they are using SSL then it might not be safe. In that case, they should be using secure VPNs…
- 20:40:45 [DKA]
- Dan: Isn't someone like EFF already providing that advice to end users?
- 20:41:17 [masinter]
- masinter has joined #tagmem
- 20:41:22 [DKA]
- Yves: yes - EFF worked on https everywhere - working against fire sheep - but this can give the sense of false security. You need a bit of judgement.
- 20:41:44 [DKA]
- … do you want to access sensitive data on a network with https if you think you might be snooped on.
- 20:42:10 [DKA]
- JAR: The point of the 3 proposed improvements is that thinks don't have to be as bad as they are.
- 20:42:21 [DKA]
- … question of how do you bootstrap trust...
- 20:42:39 [DKA]
- … my intuition is tat it's important. Can we weigh in, review the solutions, etc…
- 20:42:55 [DKA]
- JeniT: Larry suggests we get someone to brief us on these solutions.
- 20:43:06 [DKA]
- JAR: What can w3c do?
- 20:43:59 [masinter]
- Mark also pointed at https://datatracker.ietf.org/wg/dane/charter/ effort in this area
- 20:44:01 [DKA]
- Tim: One intriguing thing - they use the same keys for webid, ssl and ssh. If you use a key from one world in another world then you won't have to have on trust system for each domain (web sites, email, etc…).
- 20:44:17 [DKA]
- … with some interoperability you could use a mixture of different sources of trust.
- 20:44:47 [DKA]
- … if you join a group (e.g. an employer), you can get some certificates and a level of trust within that group.
- 20:45:27 [DKA]
- … e.g. Csail - they sign their own certs, and you have to make browser exceptions in order to use their [secure web sites].
- 20:45:55 [jar]
- timbl: trust interoperability
- 20:45:58 [DKA]
- … there should be a better way to do that - when you join a group you get trust associated with that groups including email certs, web browsing certs, etc...
- 20:47:21 [DKA]
- Dan: I think getting experts in would be good.
- 20:47:30 [DKA]
- JAR: I think Harry Halpin could do that.
- 20:48:44 [DKA]
- Ashok: I'll ask Harry to join us on a telco and talk to us.
- 20:49:44 [DKA]
- [Next step: Ashok to ask Harry to join us and brief us on the security proposals...]
- 20:50:04 [DKA]
- JAR: I recommend watching the video.
- 20:52:43 [jar]
- Looking at Harry's email http://lists.w3.org/Archives/Public/www-tag/2011Dec/0083.html
- 20:54:39 [DKA]
- Noah: One think I'd note is that web app sec as a narrower charter than web security ...
- 20:54:44 [DKA]
- Yves: yes - mostly to work on cors.
- 20:55:40 [DKA]
- Noah: Security domain lead - should we talk to Thomas and ask him "read harry's note - tell me what you're already doing about this?"
- 20:56:20 [DKA]
- Dan: could we get Harry and Thomas on the next call to discuss?
- 20:56:50 [DKA]
- ACTION: Ashok to ask harry and thomas to join us on a future TAG call.
- 20:56:50 [trackbot]
- Created ACTION-661 - Ask harry and thomas to join us on a future TAG call. [on Ashok Malhotra - due 2012-01-13].
- 21:01:47 [RRSAgent]
- I have made the request to generate http://www.w3.org/2012/01/06-tagmem-minutes.html Yves
- 21:01:54 [DKA]
- DKA has joined #tagmem
- 21:01:57 [DKA]
- RRSagent, make minutes
- 21:01:57 [RRSAgent]
- I have made the request to generate http://www.w3.org/2012/01/06-tagmem-minutes.html DKA
- 21:02:03 [DKA]
- rrsagent, make logs public
- 21:06:19 [Zakim]
- Zakim has left #tagmem
- 21:08:25 [ht]
- ht has joined #tagmem
- 22:35:49 [ht]
- ht has joined #tagmem
- 23:20:22 [ht]
- ht has joined #tagmem