14:59:03 <RRSAgent> RRSAgent has joined #ldp
14:59:03 <RRSAgent> logging to http://www.w3.org/2013/09/03-ldp-irc
14:59:05 <trackbot> RRSAgent, make logs public
14:59:05 <Zakim> Zakim has joined #ldp
14:59:07 <trackbot> Zakim, this will be LDP
14:59:07 <Zakim> ok, trackbot; I see SW_LDP()11:00AM scheduled to start in 1 minute
14:59:08 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
14:59:08 <trackbot> Date: 03 September 2013
14:59:37 <Zakim> SW_LDP()11:00AM has now started
14:59:44 <Zakim> +Arnaud
15:00:07 <gavinc> gavinc has joined #ldp
15:00:15 <Ashok> Ashok has joined #ldp
15:00:16 <Zakim> +[IBM]
15:00:38 <SteveS> Zakim, [IBM] is me
15:00:38 <Zakim> +SteveS; got it
15:01:37 <Zakim> +??P19
15:01:42 <Zakim> +bblfish
15:02:00 <bblfish_> hi
15:02:11 <Zakim> +??P20
15:02:13 <nmihindu> Zakim, ??P19 is me
15:02:14 <Zakim> +nmihindu; got it
15:02:27 <nmihindu> Zakim, mute me
15:02:27 <Zakim> nmihindu should now be muted
15:03:04 <Zakim> +JohnArwe
15:03:13 <JohnArwe> JohnArwe has joined #ldp
15:03:22 <Zakim> +??P32
15:03:27 <pchampin> zakim, ??P20 is me
15:03:27 <Zakim> +pchampin; got it
15:03:28 <BartvanLeeuwen> Zakim, ??p32 is me
15:03:28 <Zakim> +BartvanLeeuwen; got it
15:03:35 <pchampin> zakim, mute me
15:03:37 <Zakim> pchampin should now be muted
15:03:41 <Zakim> +Ashok_Malhotra
15:04:13 <Zakim> +??P35
15:04:44 <Zakim> -??P35
15:04:50 <Zakim> +TimBL
15:05:13 <Zakim> +??P44
15:05:36 <Arnaud> zakim, who's on the phone?
15:05:37 <Zakim> On the phone I see Arnaud, SteveS, nmihindu (muted), bblfish, pchampin (muted), JohnArwe, BartvanLeeuwen, Ashok_Malhotra, TimBL, ??P44
15:05:45 <rgarcia> zakim, ??P44 is me
15:05:45 <Zakim> +rgarcia; got it
15:06:17 <JohnArwe> sandro, you joining call?
15:06:29 <timbl> timbl has joined #ldp
15:06:34 <JohnArwe> ericP, you joining call?
15:06:52 <ericP> oops, tx for reminder
15:07:16 <JohnArwe> I can scribe...
15:07:28 <JohnArwe> scribe: JohnArwe
15:08:19 <JohnArwe> TimBL unable to attend F2F next week, using this call to understand any additional context on comments raised on list
15:08:26 <Zakim> +EricP
15:08:45 <JohnArwe> ...so WG can have a better chance of resolving them in a way likely to be acceptable to everyone
15:09:24 <JohnArwe> Arnaud: need to respond to all comments on list, TimBL's not special in that sense.
15:10:08 <JohnArwe> Arnaud: deal with higher level ones on call,  smaller ones via email.  Try to discuss direction, how it got here, what the big animal issues are.
15:10:17 <JohnArwe> Arnaud: more comments coming, per last email?
15:10:47 <JohnArwe> TimBL: have not found time to type them up, but they have the same ilk
15:11:24 <JohnArwe> ... many would change anyway if some of the basic issues were addressed.  e.g. what kind of interop is the goal.
15:11:42 <JohnArwe> ... spec has to require things of clients and servers so they can meet in the middle.
15:11:48 <JohnArwe> ...why so many SHOULDs?
15:12:35 <JohnArwe> ... what's provided above a basic http server?  should we have a separate profile?
15:13:26 <JohnArwe> Arnaud: history = driven by 2 somewhat conflicting goals; (1) domain-specific servers exist and they want to add an LDP interface to it, like our bug tracker example.
15:13:53 <JohnArwe> ... Those servers are not RDF-based, own internal models, constrain what they store to set fields.
15:14:19 <JohnArwe> ... (2) general RDF store which lacks those constraints on what it stores, so you can demand a lot more from the server
15:15:41 <ericP> i like to exemplify the app-specific LDP app with a controller for a light switch. if you send it triples that don't reflect in a state of the light switch, you'll not see them on a GET
15:15:50 <Zakim> -nmihindu
15:16:40 <Zakim> +??P19
15:17:03 <nmihindu> Zakim, ??P19 is me
15:17:03 <Zakim> +nmihindu; got it
15:17:20 <nmihindu> Zakim, mute me
15:17:20 <Zakim> nmihindu should now be muted
15:17:46 <Zakim> + +1.540.898.aaaa
15:17:53 <davidwood> Zakim, aaaa is me
15:17:53 <Zakim> +davidwood; got it
15:18:23 <JohnArwe> TimBL: domain specific server does not have to implement put/patch; how does client know what to use?  either lots of out of band info required => don't really have a spec.  sounds as if the client lib has to be the kind of thing that iterates through "try X, oh it fails argh, try Y...".  Domain specific doesn't matter there.  I'd like to see the plain vanilla spec first; simpler, allows you to build client apps that are all client-side.
15:18:35 <ericP> q+ to say that i was hoping that support libraries for app-specific clients would show us the value of the app-specific profile
15:19:24 <JohnArwe> ...Vanilla case is really important.  Even in case where extra constraints exist, you need ability to specify how to change triples; I need PATCH, and I need a PATCH format.
15:19:45 <davidwood> Zakim, mute me
15:19:45 <Zakim> davidwood should now be muted
15:20:30 <JohnArwe> Arnaud: everyone in WG *wanted* PATCH, but need at least one patch format for real interop.  since we did not have time to define one, but it on the side and running that discussion in parallel so we can rely on it in next version of LDP.  That's intent.  We can discuss timing.
15:20:46 <Zakim> -EricP
15:21:00 <Zakim> +EricP
15:21:37 <JohnArwe> ... You also said in email LDP is only useful in RW mode, if server is RO then no different than HTTP; want to point out that the notion of containers and paging are counter-examples, things LDP provides not in HTTP.
15:21:45 <JohnArwe> TimBL: paging optional?
15:21:52 <JohnArwe> SteveS: yes
15:23:35 <JohnArwe> TimBL: if can be initiated by server, than mandatory on client.  you need to say that.  b/c you have to meet in the middle, whenever the server has an option, then the client MUST handle it.  and vice versa.  That's how you get interop.  Agree that paging is valuable.
15:24:01 <JohnArwe> Earlier question: does current spec say client can initiate paging?  should not.
15:24:49 <JohnArwe> Arnaud: can we agree there is still use for LDP in RO case, so we don't have to discuss that further?  I think that's really the most important point in your comments.
15:25:14 <betehess> betehess has joined #ldp
15:25:16 <Zakim> -EricP
15:25:27 <Zakim> +EricP
15:26:06 <JohnArwe> ... I've been uncomfortable with SHOULDs; Raul ran into that with testing.  So I agree it's an interop problem; how do you think we can improve interop without throwing out the domain-specific server case?  We have a lot of people with those to consider as well/
15:26:18 <ericP> q?
15:26:41 <davidwood> +1 to Arnaud.  Businesses need domain-specific functionality.  I would love to see an agreement on PATCH, though.
15:27:34 <JohnArwe> TimBL: happy to work toward both goals; patch format: code in our RDF lib sends subset of sparql update with MIME type of sparql update, so defining that as simple subset would really help you.
15:28:06 <JohnArwe> Arnaud: Sandro helped look at options, after few months he was not comfy moving forward so we had to put it aside.
15:29:28 <JohnArwe> TimBL: I can see PATCH is the issue; maybe in spec we put the intent, so people do it.  For PUT/DELETE, say must be supported, but let the Authorization get out jail free card is possible, e.g. a RO server could always respond with 403.
15:29:58 <JohnArwe> ... question: if PUT triples to domain specific server, do I get a 200 back and triples silently discarded?
15:30:37 <dret> dret has joined #LDP
15:30:43 <JohnArwe> ... PUT spec says must allow entire thing, so what happens with domain-specific server on PUT?
15:30:49 <timbl> "1 If HTTP PUT is performed on an existing resource, LDPR servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."
15:31:00 <Zakim> -EricP
15:31:03 <JohnArwe> SteveS: either discards the triples or 4xx.
15:31:07 <Zakim> +EricP
15:31:12 <JohnArwe> TimBL: 4.5.1
15:31:14 <Zakim> + +1.510.206.aabb
15:31:23 <JohnArwe> SteveS: look at MAY
15:31:49 <JohnArwe> TimBL: that doesn't cover triples where server does NOT know better (server managed)
15:31:54 <JohnArwe> SteveS: 4.5 covers that
15:32:44 <JohnArwe> TimBL: if server ever can, clients MUST assume (spec says Should) it can happen.  it's not just set of predicates, it's arbitrary constraints on graph.
15:32:50 <dret> zakim, +1.510.206.aabb is me
15:32:50 <Zakim> +dret; got it
15:33:08 <JohnArwe> ... parses sentences on client that target the GET/PUT round trip.
15:33:29 <bblfish>  http://www.w3.org/TR/2013/WD-ldp-20130730/#http-put
15:33:33 <Zakim> -EricP
15:33:36 <Zakim> +EricP
15:33:41 <JohnArwe> ... see that point.  vanilla client has no idea it's talking to a domain-specific server.
15:35:02 <JohnArwe> Arnaud: maybe this is really the problem we have in spec today, "silent failure".  As you know we have RDF validation workshop next week, that's what we've been using to allow clients to discover these server features.  Henry raised that on list.
15:35:32 <JohnArwe> TimBL: one of nice things about defining new spec is you can define new codes.  You can define 20x as I described instead of 303.
15:36:02 <ericP> 218½: i'm not storing exactly what you PUT
15:36:23 <timbl> Important for spam control for example
15:36:46 <JohnArwe> ... similarly you could define a 20x to say "I understand what you said, but you didn't get an exact store"... if client wants to know exactly what happened, can look at server capabilities (assuming available via hypermedia etc online)
15:36:56 <JohnArwe> zakim, who's making noise?
15:37:00 <sandro> Zakim, what is the code?
15:37:00 <Zakim> the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), sandro
15:37:07 <Zakim> JohnArwe, listening for 10 seconds I heard sound from the following: Arnaud (54%), SteveS (36%), TimBL (9%), EricP (24%)
15:37:21 <JohnArwe> ericp you might want to mute
15:37:22 <Zakim> +Sandro
15:38:00 <sandro> (sorry, somehow this was in my calendar for the Friday timeslot instead)
15:38:32 <JohnArwe> TimBL: at the moment, you don't have a way to define all metadata.  client should be able to proceed w/o metadata to update things; if it gets error codes, it can branch off to limited server code or ask human to find more capable server.
15:38:39 <JohnArwe> ... silent failure is terrifying.
15:40:30 <JohnArwe> ... With more MUSTs on server, we can write more stuff on client side like [???].  way I'm using it, when you change field in form, the server is updated w/in fraction of second.  you can't afford extra round trip.  if you have to do an OPTIONS/HEAD to find out how to use this thing.  Not going to be able to more than GET.
15:40:42 <JohnArwe> ... was not clear what's in OPTIONS that's not in headers.
15:41:01 <bblfish> Timbl: a major criteria is that one should reduce the number of connections in the spec. This could be tested by looking at how test suites. Better to create HTTP codes than to have redirects.
15:41:49 <JohnArwe> Arnaud: options added late, allows obtaining same data w/o overhead of calculating some HEAD fields.  People at conferences were happy to see us doing OPTIONS as lighter version of HEAD.
15:41:59 <ericP> it's true, content-length is a very expensive header field in a response to a HEAD
15:42:11 <davidwood> WebSockets instead? :)
15:42:15 <JohnArwe> TimBL: oh seemed like OPTIONS was heavier than HEAD
15:42:22 <davidwood> (not really proposing it)
15:42:28 <bblfish> Timbl: Doing Options + GET is more expensive than just GET.
15:42:29 <JohnArwe> ...are all headers on GET?
15:42:48 <JohnArwe> Arnaud: yes.  anything you see on OPTIONS/HEAD you'll also see on GET response.
15:43:28 <bblfish> q+
15:43:56 <JohnArwe> TimBL: protocol is little system, who does what.  quite a bit of text about what server could do, need to (a) must it (b) show more of what client does perhaps as kind of flowchart
15:44:23 <JohnArwe> ... if flow for vanilla client gets complex, you can see the problem
15:44:34 <SteveS> q+
15:44:44 <Arnaud> ack ericp
15:44:44 <Zakim> ericP, you wanted to say that i was hoping that support libraries for app-specific clients would show us the value of the app-specific profile
15:46:14 <JohnArwe> ericp: good to try understand spec value; would app-specific show us what should be shoulds/musts?  tim, would you be happy if spec was written for app-specific only, but provided basis for generic (specific is restriction of generic)
15:46:34 <JohnArwe> TimBL: no, upside down.  start with clean smoot platform, then express exceptions.
15:46:48 <Ashok> +1 to TimBL on Vanilla spec
15:47:33 <JohnArwe> ... MUST support PUT, MUST NOT change client's input.  very basic, testable, invariants.  important for writers, caches.  smaller spec; leave hooks for domain-specific systems.
15:48:20 <JohnArwe> ... we've defined 208.5 code with Link header to more specific sub-protocol.  client can do SOME things from generic, but not all.
15:48:47 <JohnArwe> ericp: I see it other way; generic= MUST preserve, app-specific says MAY throw away triples
15:49:51 <ericP> i don't see how you base a less restrictive spec on a more restrictive spec.
15:49:51 <JohnArwe> Arnaud: have been trying to figure out how this differs from authorization, security, etc.  even if spec has MUST, it's understood that a single request might fail (due to lack of auth, say) w/o "violating" must.  we accept these things as being beyond the spec.
15:49:58 <Arnaud> q?
15:50:35 <JohnArwe> TimBL: referring to HTTP is a separate issue; all the examples you came up with are covered there.
15:51:12 <bblfish> Timbl: ie access control has an HTTP code that deals with it.
15:51:16 <Arnaud> ack bblfish
15:51:21 <JohnArwe> Arnaud: point is, there are diff levels of constraint exist.  maybe we should have some way for clients to find out if they're talking to RO/whatever servers.  see value in defining vanilla level that might be much more demanding.
15:54:10 <JohnArwe> bblfish: +1, need to build explicit things, work out how to move from generic client to specific one.  we added OPTIONS b/c spec had options instead of pushing it off to access control.  email w/in last hour: POST has side effect of creating resource; what is client responsible for on POST?  POST + shopping cart = buy action ==> user responsibility.
15:54:41 <Arnaud> ack steves
15:54:42 <ericP> bblfish, it what way are the property names and grpah paterns insufficient for defining the semantics of the shopping cart POST you described?
15:55:43 <ericP> i believe that the grounding of terms in the message is exactly why martin nally wanted to use RDF in the first place
15:55:49 <JohnArwe> SteveS: bug example, going back to flowchart comment... client GETs on bug (no OPTIONS reqd), look at headers.  other alternative is send something on GET response therefore you have some extra verbs available.
15:56:57 <JohnArwe> TimBL: one idea, allow 2 types on type header you already have.  one for LDPR, allow others.  client could look up others to find out if subclass of LDPR/etc
15:57:13 <JohnArwe> Arnaud summarizes
15:57:25 <JohnArwe> - Greater level of interop in RW mode
15:57:47 <JohnArwe> - OK if hook exists for client to find other restrictions
15:58:01 <JohnArwe> TimBL: patch language is so much more important
15:58:40 <JohnArwe> Arnaud: what spec can we point to for what "we" are using today?  Sando: Turtle patch web page, was one input.  Tim, what do you do about blank nodes?  That's where it got hard.
15:58:49 <JohnArwe> s/Sando/Sandro/
15:58:57 <timbl> For blank node id, there is a WHERE
15:59:09 <JohnArwe> Sandro: Tim, you and I can help move the task force forward
15:59:31 <JohnArwe> TimBL: just want to modify RDF graph; need Where clause for Bnodes
15:59:44 <JohnArwe> ... took 2 lines of JS
15:59:57 <JohnArwe> Sandro: still NP complete, can take forever to run
16:00:00 <bblfish> while ( true ) print "hello"
16:00:02 <JohnArwe> ...scares people
16:00:12 <bblfish> oh dear! a p[iece of code that is np complete.
16:00:40 <JohnArwe> ... spirited discussion of why, in practice, theory != reality
16:00:40 <bblfish> JS is NP Complete. Everybody uses it :-)
16:01:03 <bblfish> ( sorry )
16:01:20 <JohnArwe> Arnaud: wrapping up
16:01:32 <JohnArwe> Several: continue... Tim available into part of lunch
16:02:33 <JohnArwe> Arnaud: so you're saying a limited solution is better than none, for patch format?
16:03:09 <JohnArwe> TimBL: write examples/BNF, point out subset... yeah everyone really wants it, let's push on it.
16:03:13 <timbl> a etstsuite
16:03:17 <timbl> a etst suite
16:04:20 <Zakim> -davidwood
16:04:39 <JohnArwe> Sandro: works fine in good cases, for right datasets.  for wrong datasets, e.g. with list containing few hundred elements, takes much longer.  people used to that in sparql.  but in patch, is making a simple operation hard worth it?  if we had round-trippable bnode labels it would be linear.
16:04:45 <Arnaud> q?
16:05:35 <ericP> SPARQL WG spent a while talking about "told BNodes" and gave up
16:06:04 <ericP> i'd not expect to constrain systems to remember the BNode labels they invented when serializing
16:06:32 <JohnArwe> Discussion of patch format issues/ideas
16:06:52 <Zakim> -BartvanLeeuwen
16:10:26 <JohnArwe> Arnaud: if you can come up with something in reasonable time window, everyone would love to have it.
16:10:53 <JohnArwe> TimBL: would things go better/faster if spec introduced notion of a vanilla server?
16:11:33 <bblfish> seems good to me to make the distinction between two servers
16:11:36 <JohnArwe> ... spec constraints can then be associated with one class vs others
16:11:43 <JohnArwe> ... still needs a lot more MUSTs
16:12:28 <JohnArwe> Arnaud: WG needs to figure out which SHOULDs can become MUSTs, and how to accomodate both types of server.
16:12:29 <SteveS> it would be a good exercise to see if we can tag our reqs/scenario with which type of server they are
16:12:58 <JohnArwe> TimBL: if it's a bit, you can put in headers.  if more complicated, you need a richer language.
16:13:34 <JohnArwe> Arnaud: I just saying figuring out which constraints apply to vanilla (as MUST) vs domain is a WG activity
16:14:20 <JohnArwe> Arnaud: another comment I wanted to ask about is the Page resource; right now all done in RDF level, you wanted to move it header.  in general where do you draw the line where to put it?  WG had LOTS of discussion on placement.
16:16:15 <JohnArwe> TimBL: for me, a data store is a store of quads: subj, predicate, object, resource ID.  you can just send a patch to a resource for update.  great model for building apps.  do hit problem that app works fine, then you run into scaling issue.  most bits of generic sw need something like paging.  to me it seemed clear part of http layer, and valuable there.
16:17:13 <JohnArwe> ... Want client to be able to say LIMIT(10K) like on cell phone/constrained env.
16:17:27 <JohnArwe> ericp: problem is hard to apply that to generic triple store.
16:17:30 <bblfish> Timbl: headers that would allow one to limit the triples you get.
16:18:15 <JohnArwe> EricP: ...discussion
16:18:48 <bblfish> ... allowing the triple store to break it all up into chunks.
16:19:04 <JohnArwe> TimBL: triple store could arbitrarily break up data into chunks... talking about reasons for doing things in http instead
16:19:05 <bblfish> ... by moving it to the HTTP layer
16:19:56 <JohnArwe> TimBL: you'd know if someone wanted to do a SPARQL query over the logical resource (that gets paged at the http resource level)
16:20:18 <JohnArwe> ericp: do this as named graphs in trig
16:21:18 <JohnArwe> TimBL: maybe I'm wrong, but when I looked at paging stuff the only crucial bits were the links between pages.  rel=next/prev/part
16:21:33 <timbl> rel = page:{partOf,next,prev}
16:21:46 <JohnArwe> ericp: makes sense; possible that's in existing client libs
16:21:55 <bblfish> q?
16:21:57 <JohnArwe> ... UK example given
16:21:58 <bblfish> q+
16:22:29 <JohnArwe> Arnaud: Tim in camp that prefers HTTP headers, but ok if left as is?
16:23:04 <timbl> (s,p,o,r)
16:23:08 <JohnArwe> TimBL: I wouldn't use it; can't have magic triples appear in payload if the axiom is that server does not modify the triples sent by clients except in response to client requests
16:23:27 <timbl> In a vanilla server,
16:23:30 <JohnArwe> Arnaud: sounds like vanilla httpd server
16:24:17 <JohnArwe> TimBL: no, vanilla LDP server.  invariant: if client writes (s,p,o,r) into server, then resource r will contain triple (s,p,o).  extension of webdav model, if you like.
16:25:21 <JohnArwe> ... similar to what happens with servers that accept "any" media type and then, once you put them in there, it will serve them faithfully
16:25:37 <JohnArwe> ...easy to test, build clean stuff on top of that
16:26:42 <JohnArwe> Arnaud: clarify - you want client to be in full control.  even in that case, ex client just adds triples daily, after 2 years GEts, you're expecting one 200 response?
16:26:43 <pchampin> q+
16:27:25 <ericP> GET /bigLog
16:27:25 <JohnArwe> TimBL: no, 208.5 response "I gave you part of it", Location tells you URI, and link headers give you the next/part of headers
16:27:43 <JohnArwe> s/of headers/of the resource/
16:27:45 <ericP> HTTP/1.1 208½ try this instead
16:28:14 <ericP> firstPage: /bigLog/p1
16:28:22 <Arnaud> ack bblfish
16:28:24 <ericP> nextPage: /bigLog/p2
16:28:27 <ericP> .
16:28:39 <JohnArwe> TimBL: pagination is great to build in, want at low level so libs will build it in, so clients get it for free.  alternative would be apps grow to certain pt then have to rework things later.
16:29:03 <JohnArwe> bblfish: you said before different clients get different size responses?
16:29:39 <JohnArwe> TimBL: search engine wants to stream in large data; tabulator style web app should always be putting limits on their requests
16:29:50 <JohnArwe> ... sorting makes sense
16:30:15 <JohnArwe> ... no point in sending data app can't cope with, cell phone/slow links
16:30:19 <timbl> Limit: 10000
16:30:26 <JohnArwe> ... at the moment done by bytes
16:30:32 <JohnArwe> ... hint from client
16:30:43 <bblfish> thanks
16:30:47 <JohnArwe> ... suggesting page size client could handle
16:30:54 <pchampin>  zakim, unmute me
16:30:54 <Zakim> pchampin should no longer be muted
16:30:55 <Arnaud> ack pchampin
16:31:28 <ericP> note that client-selected size is slightly at odds with persistent URIs for the pages
16:31:38 <JohnArwe> Pierre: reaction to "no magic triples".  Magic triples not added to resource, they're a separate resource that explains how it relates to original.  Is that as bad?
16:31:45 <pchampin> zakim, mute me
16:31:45 <Zakim> pchampin should now be muted
16:31:55 <ericP> so far, the paging has no need to be dynamic. you can statically store the pages
16:32:24 <JohnArwe> TimBL: don't think so, my app already has lots of magic triples.  under the covers there's a whole bunch of data about the http request.
16:32:57 <pchampin> ok, thx
16:33:12 <JohnArwe> ... from that I can conclude it's type, from MIME type, so I'm already used to 2 layers, and if HTTP is already doing metadata I'm happy to let the next/prev links be there too.
16:33:23 <JohnArwe> Arnaud: anything you want to hit before we stop?
16:33:27 <SteveS> Hopefully timbl can get the other comments in by next week
16:33:59 <JohnArwe> TimBL: have not talked about conneg; hopefully no need to discuss that.
16:34:39 <Zakim> -EricP
16:35:01 <Zakim> -bblfish
16:35:08 <Zakim> -dret
16:35:17 <Zakim> -Ashok_Malhotra
16:35:18 <Zakim> -TimBL
16:35:19 <Zakim> -SteveS
16:35:20 <pchampin> bye bye
16:35:21 <Zakim> -Sandro
16:35:22 <Zakim> -JohnArwe
16:35:23 <Zakim> -rgarcia
16:35:26 <Zakim> -Arnaud
16:35:30 <Zakim> -pchampin
16:35:39 <Arnaud> timbl, Bon Appetit! :-)
16:40:30 <Zakim> disconnecting the lone participant, nmihindu, in SW_LDP()11:00AM
16:40:31 <Zakim> SW_LDP()11:00AM has ended
16:40:31 <Zakim> Attendees were Arnaud, SteveS, bblfish, nmihindu, JohnArwe, pchampin, BartvanLeeuwen, Ashok_Malhotra, TimBL, rgarcia, EricP, +1.540.898.aaaa, davidwood, dret, Sandro
16:56:06 <stevebattle4> stevebattle4 has joined #ldp
17:01:33 <stevebattle4> stevebattle4 has joined #ldp
17:01:46 <SteveS> SteveS has joined #ldp
17:52:54 <bblfish> bblfish has joined #ldp
18:43:42 <Ashok> Ashok has joined #ldp
18:44:01 <Ashok> zakim, pointer?
18:44:01 <Zakim> I don't understand your question, Ashok.
18:45:23 <Ashok> rrsagent, pointer?
18:45:23 <RRSAgent> See http://www.w3.org/2013/09/03-ldp-irc#T18-45-23
18:51:00 <bhyland> bhyland has joined #ldp
19:12:09 <bblfish> bblfish has joined #ldp
19:21:51 <betehess> betehess has joined #ldp
20:36:38 <bblfish> bblfish has joined #ldp
21:01:11 <Zakim> Zakim has left #ldp
21:06:42 <betehess> betehess has joined #ldp
21:27:19 <bblfish> bblfish has joined #ldp
21:27:47 <bblfish_> bblfish_ has joined #ldp
21:30:14 <bblfish> bblfish has joined #ldp
21:42:48 <bblfish> bblfish has joined #ldp