[01:37:55] --- julian.reschke has joined [02:25:30] --- julian.reschke has left [05:27:42] --- j.schoenwaelder has joined [05:46:31] --- julian.reschke has joined [05:50:02] --- yone has joined [06:06:14] --- fenton has joined [06:08:54] --- Barry Leiba has joined [06:11:05] --- Ted has joined [06:11:13] --- apn has joined [06:11:21] --- rohan has joined [06:11:22] --- narten has joined [06:11:25] Agenda bash portion of agenda up now [06:11:36] --- frodek has joined [06:11:37] --- tonyhansen has joined [06:11:42] (isn't the room topic left over from the last IETF)? [06:11:50] --- Lisa has joined [06:11:57] Thanks Ted [06:12:09] New discuss list name apps-discuss@ietf.org [06:12:20] Change due to subdomain changes in transition and avoiding complexity [06:12:21] --- resnick has joined [06:12:27] --- ray has joined [06:12:28] --- shinta has joined [06:12:30] --- koji has joined [06:12:37] /ted where's the agenda? [06:12:39] Discussion of APPS Area Workshop now up [06:12:47] --- jlcjohn has joined [06:12:54] Julian: Is it not on the proceedings site? [06:12:54] --- atarashi has joined [06:13:07] It was not this morning. [06:13:12] Agenda bash/apps workshop/ BoF Discussion is the basic flow [06:13:20] --- levigner has joined [06:13:45] Barry will overview, bcp 56 update, http auth, mail store architecture and design guide are the sub-bullets in Apps Workshop [06:14:01] lisa is stalling while Barry preps. [06:14:08] Ted: not on https://datatracker.ietf.org/meeting/71/agenda.html. [06:14:15] Oops, *Chris* is stalling while Barry preps. [06:15:09] * resnick sends private IM sent to Lisa asking to do so.... [06:15:28] She acks and will do so. [06:15:43] Barry is up now, first slide: Workshop Goals [06:16:03] Examine architectural gaps, explore sensible reuse of existing standards, brainstorm, kick off new work [06:16:08] --- Chris Newman has joined [06:17:03] Format: breakout topics identified, breakout sessions went into specific topics in detail; then plenary discussion of breakout topics [06:17:30] Break topics: use of http for more than web (updating BCP 56); protocol layering, localization and identity, synchronization [06:17:53] protocol layers: looking at how protocols at the applications layer interact with those at the transport and network layers [06:17:58] (lots of noise on the audio stream; maybe move closer to the mic?) [06:18:22] (not scribe comment: when I do it, is an optimization. When someone else does it, may be layer violation) [06:19:15] XML schemas, URI templates, HTTP authentication, Email re-architecture are other Breakout topics [06:19:35] --- Randall Gellens has joined [06:19:39] HTTP Authentication: avoiding things that are easy for fishers [06:19:55] --- klaas has joined [06:20:05] Email re-architecture: would it be wise to do some major redesign of email retrieval and storage [06:20:22] Other topics: push/pull/notify as an alternative to polling [06:20:42] Protocol Architecture Guide: infromational document with what we've learned that works and what we believe does not. [06:21:10] Pete is getting up to speak now [06:21:14] --- Jelte has joined [06:21:45] Chris is looking for the mail [06:21:46] Found [06:21:49] --- hta has joined [06:22:08] Pete's slides:Toward a simpler Email Architecture [06:22:12] What is Pete up to? [06:22:25] No, he is not suggesting "replace all of Internet e-mail" [06:22:34] SMTP, Message Format, MIME remain the same [06:22:39] this is about a replacement for IMAP [06:23:32] IMAP architected at a time when message stores were more limited and in a way that exposed the semantics of existing, deployed server implementations [06:24:01] Client ends up with Herculean task of guessing what the server implementations are, through the protocol [06:24:05] Main features: [06:24:08] No more mailboxes [06:24:12] No more folders [06:24:23] Message store is a database of objects [06:24:41] 3 object parts: message objects, multipart objects, terminal objects [06:24:57] Objects shared across containers/stores [06:25:28] Message objects: contain one multipart of terminal objects, has a uid, source and transport info [06:25:40] --- fujiwara has joined [06:25:56] Multipart objects= contain one or more message, multipart, or terminal objects, and has type attribute and other info [06:26:09] Terminal objects--contain data, has a type attribute and other information [06:26:29] client operations in this model [06:27:00] authentication, search for messages, retrieve objects or attributes, store objects, delete message clients, delivery is just another client [06:27:56] A hierarchy of messages is client, not message store action [06:28:54] Slide: Security what Security? [06:29:07] He did not deal with encrypted objects or access control [06:29:56] --- klaas has left [06:30:07] So what do we do with this? [06:30:14] This is an architecture, not an implemetnation [06:30:21] implementation discussed at workshop [06:31:16] There were various thing said like: should be xml based, it should be done with http; it should be done with a completely new protocol. Toools should be brought to architecture, architecture should not be changed to suit tools [06:31:33] Need at least a couple of implementations to get started [06:32:54] Dave at the mic [06:33:17] not yet an architecture [06:33:23] a long way from implementation [06:34:25] There is a whole collection of things that motivates the choices that you've made. [06:34:31] He's suggesting some directions to go. [06:35:03] Pete: preservation of message encodings etc. was not a requirement [06:35:14] A stable mapping is a requirement [06:35:31] Dave: this explanation shows more is needed [06:35:40] --- matthijs has joined [06:35:50] Pete: the key thing that he is looking to address are: in IMAP operations assume a select [06:36:04] talk about a mailbox, then piece of the storage [06:36:28] In IMAP, you mark things for delete, then expunge or servers helpfully expunge them for you [06:36:45] There is a whole list of options that need to go away [06:37:00] He wants to head in that directions [06:37:03] --- john.zhao has joined [06:38:02] Dave suggests an approach: i hear "we want to do this differently from IMAP", but "use the lessons from IMAP" is a different and better way to go about this. [06:38:13] Lisa: we do have an interoperability problem [06:38:43] (Talks about filing, and how client behavior relates) [06:39:27] Opera mail and gmail discussed [06:40:34] Lisa does not want to be an architecture astronaut [06:40:59] Thomas feels that it is not clear yet what problem is being solved. [06:41:40] Pete is looking for implementors, but for architectural bent + knows what a compiler and maybe a product connection (so could think of impact) [06:42:08] Thomas is hearing compelling problems [06:42:49] The server implementors are the ones that might object here; client implementors likely to have strong desire for this [06:43:10] Randy: there have been attempts to learn the painful lessons of IMAP [06:43:19] --- cabo has joined [06:43:23] ACAP was designed with the lessons of IMAP in mind [06:43:40] --- alexey.melnikov has joined [06:43:51] IMAP has too many implementations of IMAP that don't implement IMAP [06:44:15] Clients that have to deal with that have huge issues to struggle with [06:44:47] Pete is looking for "prototypers' [06:44:57] nice wording [06:45:13] Can someone jabber scribe while I get to the mic? [06:45:34] Pete and Randy are talking about optionality [06:45:49] tag [06:45:56] Randy believes that's only part of the problem, that subtlety is an issue [06:46:13] meta-question: how much time [06:46:22] chris: we have time [06:47:16] --- atarashi has left: Replaced by new connection [06:47:25] dave: an example of danger of viewing this as architecture are implications that may be wrong: eg protocols have choice of where to put complexity, may have made clients more complicated but protocol simpler [06:47:58] dave: you're looking for "architects who have a clue about implementing" [06:48:26] dave; are you really describing the web? attributes: post [06:49:24] cyrus: concerned, looking at past problems of email, but that's a moving target, people looking at new things in email and need to look at forward scope, calendaring - rss - social web - etc [06:49:45] (to the remote participants: is audio working for anybody?) [06:50:12] pete: let's solve "a problem" with an eye toward those other problems in this arch, msgs have some primacy, but no need for other access mechanisms to give same primacy [06:50:31] pete: gives examples [06:51:47] pete: has a problem with solving all the problems from the get go. solve msging problem first off the wall questions " can I do this with that" are good, as long as extensible enough [06:51:50] --- Chris Newman has left [06:51:54] cyrus: call it "object store" [06:52:24] pete: start w/ object store, or msging store that has enough semantics that can be moved into object store later [06:53:04] cyrus: as a client author, want my client to stand out, don't want all clients to act same way [06:53:52] pete: with rich semantics, clients can do lots of interesting things how to map current semantics on top of new semantics (folder heirarchy) [06:55:33] --- atarashi has joined [06:56:26] ted: you have a circularity: abstract from old msg stores, but new arch still focuses on object store and not on: what's this action like and how can I make it better? what is it somebody needs to do? [06:56:45] pete: yes you're right, but... [06:57:12] tony, I can tag back in [06:57:52] Pete: we don't want tie this to a storage model, but we want to hold on to user operations on kinds of object [06:57:59] object semantics do need to be exposed [06:58:11] pete: balance only what's on wire, lose track of important operations need to contend with, do want to hold on to user operations on certain kinds of objects, maybe not some object semantics but object semantics do need to be exposed [06:58:14] Lisa: going back to discussion of complexity [06:58:25] We can push complexity around, and that can be very useful [06:58:53] Lisa has a personal hope that you can have a very low barrier to entry to have some tool that is not a UA ask for a message [06:59:05] This enables mash-ups to all kinds of other activities [06:59:13] group productivity apps, web sites, calendars, etc. [07:00:03] Dave: we should focus on what we want to do, not on what we've got. [07:00:12] The follow-on is "between what and what" [07:00:34] Dave suggests Pete sees that as "between the user and their data" [07:01:29] Dave believes that the generality is not as big a deal here as it might be. A way to displace the existing protocol might be with generality [07:02:17] Dave thinks what you're describing is too basic [07:02:51] He keeps coming back to the idea that the work isn't well enough motivated--the dissatisfaction is evident, but the user base, dissatisfied as it is. [07:03:00] Phil: it's a beautiful, beautful dream [07:03:06] --- hta has left [07:03:07] er, beautiful [07:03:35] He says the take-up problem on the client side. [07:03:49] is the installed base [07:03:59] Making a reference to the suit of armor in the corner. [07:05:38] (I got a little lost following Phil) [07:06:32] --- apn has left [07:06:45] Pete is saying that going down a path with other things in mind (general enough to deal with mail, atom, calendaring) is a different approach. You start with one, then others can use other "primary ontological entities" [07:07:10] The main problem, though, is getting folks on board for doing *their* piece [07:08:14] Pete is complimenting Chris's message store, and saying that it currently has IMAP on top. He could have a parallel access protocol based on this. [07:08:38] pop/imap/new is complicated, but it gives you a way out of the pain [07:12:02] Discussion of what "message" means in a modern context [07:12:14] An arbitrary move to get the right thing done [07:14:33] Perhaps we can we have a less ambitious goal - start with documenting existing mailstore architecture as covered by POP and IMAP? [07:14:51] Dave asks the question up a level--what' the interest in proceeding (as opposed to this approach to proceeding) [07:17:24] Chris re-iterates the need for "prototypers" [07:18:57] Going through the idea of protocol design guides [07:19:18] At a mic, someone points out that transport is working on a "how to use UDP" draft, and input now would be great. [07:19:51] someone = Gorry Fairhurst [07:19:56] Thanks! [07:20:02] Now, onto the BoFs [07:20:19] Mark Harrison is getting up to talk about ESDS [07:21:31] ESDS BoF is Salon I at 13:00 [07:21:35] "How to chase a Bull" [07:22:51] Animated slide, showing bull being transported through farm, slaughterhouse, and onward [07:23:24] We didn't know his presentation was going to be full of bull. Hm. [07:23:46] --- resnick has left [07:24:36] Showing publish action, where end-to-end traceability is the goal (publish is one way to get them into a discovery service) [07:25:09] Next slide shows a query into a service that links into a service that allows you to answer a question like "Is my food safe for consumption" [07:25:26] It's an enabler for "track and trace" applications [07:25:28] --- trond has joined [07:26:01] Shows a protocol stack slide, showing where the ECPGlobal folks have done work [08:56:14] --- cabo has joined [09:21:12] --- j.schoenwaelder has joined [09:50:54] --- levigner has joined [09:51:03] --- levigner has left [10:03:20] --- svanegmond has joined [10:03:30] --- alexey.melnikov has joined [10:03:44] hello, scribe here [10:03:52] my first time, please give feedback if you have any [10:04:31] --- mini has joined [10:04:32] --- Andrew Sullivan has joined [10:04:54] mark harrison speaking [10:05:09] --- tonyhansen has joined [10:05:11] mark is from the BRIDGE project [10:05:31] slide: "scope of disccusion" [10:05:32] --- cabo has left [10:06:09] next slide: simple example, following a cow through the supply chain from farm to store [10:07:30] --- Barry Leiba has joined [10:07:59] --- Lisa has joined [10:08:11] for those who joined I welcome any feedback re: my scribing's level of detail or content [10:09:10] --- ray has joined [10:09:12] sidebar discussion of end-to-end traceability, surviving object composition (e.g. assembling a plane or laptop) or decomposition (breaking a container into pallets) [10:10:45] next slide: query scenario [10:11:04] example question: is this food tainted? where has it been? [10:11:15] next slide: why this is becoming interesting/important now [10:11:21] --- ray has left [10:13:02] next slide: why now? technical perspective [10:13:06] --- =JeffH has joined [10:13:28] illustration reminiscent of the OSI network stack [10:17:55] --- =JeffH has joined [10:18:04] <=JeffH> so is any reasonably developed network stack [10:18:09] --- =JeffH has left [10:20:21] --- =JeffH has joined [10:22:13] --- glen has joined [10:22:34] Your esds jabber chat room has been created [10:22:57] --- glen has left [10:24:38] --- ray has joined [10:24:42] --- ray has left [10:30:55] --- jlcjohn has joined [10:31:01] --- jlcjohn has left [10:31:02] --- j.schoenwaelder has joined [10:33:01] --- ray has joined [10:34:07] --- ray has left [10:40:51] --- julian.reschke has joined [10:49:34] --- =JeffH has left: Logged out [11:50:01] --- Eric Rescorla has joined [11:57:45] --- Eric Rescorla has left: Disconnected [12:00:08] --- Eric Rescorla has joined [12:02:55] --- Eric Rescorla has left: Disconnected [12:05:42] --- cabo has joined [12:10:09] --- Eric Rescorla has joined [12:10:52] --- Eric Rescorla has left [12:10:56] --- tonyhansen has joined [12:10:58] --- cabo has left [12:17:11] --- alexey.melnikov has joined [12:19:13] --- Barry Leiba has joined [12:19:31] --- Barry Leiba has left [12:20:24] --- Barry Leiba has joined [12:20:42] --- Barry Leiba has left [12:22:48] --- cabo has joined [12:36:00] --- tonyhansen has left [13:47:25] --- cabo has left [14:02:06] --- cabo has joined [14:31:02] --- alexey.melnikov has left