14:57:11 <RRSAgent> RRSAgent has joined #ldp
14:57:11 <RRSAgent> logging to http://www.w3.org/2014/01/27-ldp-irc
14:57:13 <trackbot> RRSAgent, make logs public
14:57:13 <Zakim> Zakim has joined #ldp
14:57:15 <trackbot> Zakim, this will be LDP
14:57:15 <Zakim> ok, trackbot; I see SW_LDP()10:00AM scheduled to start in 3 minutes
14:57:16 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
14:57:16 <trackbot> Date: 27 January 2014
15:00:06 <Zakim> SW_LDP()10:00AM has now started
15:00:13 <Zakim> +Arnaud
15:00:56 <Zakim> +Ashok_Malhotra
15:01:19 <JohnArwe> JohnArwe has joined #ldp
15:01:28 <JohnArwe> zakim seems under the weather today
15:01:51 <Zakim> +JohnArwe
15:01:55 <JohnArwe> ...just dropped me w/o asking for a code, but second try worked
15:03:06 <Zakim> +Steve_Speicher
15:03:24 <SteveS> zakim, Steve_Speicher is me
15:03:24 <Zakim> +SteveS; got it
15:04:27 <Zakim> +Matt
15:04:37 <betehess> Zakim, Matt is Andrei
15:04:37 <Zakim> +Andrei; got it
15:04:53 <Zakim> +OpenLink_Software
15:04:54 <betehess> Zakim, Andrei also has Alexandre
15:04:54 <Zakim> +Alexandre; got it
15:04:57 <TallTed> Zakim, OpenLink_Software is temporarily me
15:04:57 <Zakim> +TallTed; got it
15:06:05 <Zakim> +Roger
15:06:12 <nmihindu> nmihindu has joined #ldp
15:06:15 <TallTed> Zakim, who's here?
15:06:15 <Zakim> On the phone I see Arnaud, Ashok_Malhotra, JohnArwe, SteveS, Andrei, TallTed, Roger
15:06:17 <Zakim> Andrei has Andrei, Alexandre
15:06:17 <Zakim> On IRC I see nmihindu, JohnArwe, Zakim, RRSAgent, Ashok, SteveS, deiu, betehess, TallTed, jmvanel, Arnaud, sandro, Yves, ericP, thschee, trackbot
15:06:27 <roger> roger has joined #ldp
15:07:06 <betehess> scribe: Alexandre
15:07:10 <Zakim> +ericP
15:07:12 <betehess> scribenick: betehess
15:07:57 <betehess> Arnaud: last week, because of not enough people on the call, we had an informal call
15:08:15 <betehess> ... let's approve the minute from last meeting, 2 weeks ago
15:08:28 <betehess> ... anybody looked at them?
15:08:38 <SteveS> look fine to me
15:09:06 <betehess> ... ok let's approve
15:09:11 <betehess> ... next meeting is next week
15:09:23 <betehess> ... Feb 3rd
15:09:56 <Zakim> +??P2
15:10:28 <betehess> I guess you can close mine
15:10:30 <Zakim> +Sandro
15:10:37 <nmihindu> Zakim, ??P2 is me
15:10:37 <Zakim> +nmihindu; got it
15:10:47 <betehess> Arnaud: what about actions?
15:10:53 <betehess> ... anybody claiming victory?
15:11:17 <nmihindu> Zakim, mute me
15:11:17 <Zakim> nmihindu should now be muted
15:11:26 <betehess> ... we can close ACTION-128
15:11:57 <betehess> ... wanted to spend a minute speaking about timeline
15:12:08 <betehess> ... currrent charter expires at the end of May
15:12:23 <betehess> ... we should try having a PR before then
15:12:34 <betehess> ... think it's possible
15:12:44 <betehess> ... even if we close all issues today, still hard to get there
15:12:55 <betehess> ... can't afford to discuss new things
15:13:04 <betehess> ... people need to accept that the spec won't be perfect
15:13:20 <betehess> ... it's better if we don't have to re-charter
15:13:37 <betehess> ... so we have to prove to the w3c management that we're ready to deliver
15:14:02 <Zakim> +??P11
15:14:06 <betehess> ... also depends on the editors, but there are quite a few changes so it won't be done in one week
15:14:25 <JohnArwe> regrets: cody
15:14:31 <betehess> ... one big unknown: what we get during 2nd LC
15:14:47 <betehess> ... we may have significant comments and go to another LC
15:14:59 <betehess> ... requires negociations with the commenters
15:15:09 <betehess> ... so the timeline I drafted is an idea
15:15:29 <betehess> ... time will tell us
15:15:49 <betehess> ... we've had a lot of comments after 1rst LC
15:16:07 <betehess> ... the time for next f2f could be in 2 months from now
15:16:08 <Zakim> +bblfish
15:16:34 <betehess> ... would give us a chance to meet after the LC
15:16:59 <betehess> ... just wanted to tell people what to expect
15:17:24 <betehess> sandro: agree with general analysis, was wondering about tracking implementations/test suite for CR
15:17:38 <betehess> Arnaud: there is a wiki page tracking all that
15:17:41 <SteveS> http://www.w3.org/wiki/LDP_Implementations
15:17:44 <betehess> ... don't know how accurate it is
15:18:03 <betehess> ... what's not clear is how long it will take for people to refelct last changes
15:18:27 <betehess> ericP: what you have to do is proving that your implementation do X, Y and Z
15:18:39 <betehess> sandro: the test suite is just human readable
15:18:41 <betehess> ericP: correct
15:18:44 <SteveS> Info on "Testing" http://www.w3.org/2012/ldp/wiki/Testing
15:19:14 <betehess> Arnaud: Juan has been trying to do that but couldn't keep up with all the changes (nobody can blame him)
15:19:26 <Zakim> -??P11
15:19:27 <betehess> sandro: maybe somebody will share his code
15:19:36 <betehess> ericP: problem is for generic triplestores
15:19:46 <betehess> Arnaud: yes, there can be domain specific constraints
15:20:13 <betehess> ... will be mainly based on claims from people
15:20:30 <betehess> ericP: we do the same in other WGs, when we give them the test suites
15:20:35 <nmihindu> s/Juan/Raul
15:20:49 <betehess> sandro: we can skip CR if we meet those criterias
15:20:59 <betehess> ericP: even better if we have that for LC
15:21:17 <betehess> Arnaud: let's move on with the agenda
15:21:31 <betehess> ... Accept-POST
15:21:40 <betehess> ... written by Erik Wilde
15:21:52 <betehess> JohnArwe: erik will do some cleanup on the draft
15:22:11 <betehess> ... ask people with implementations, prototypes, intentions, to tell him
15:22:20 <betehess> ... to have an implementation report
15:22:30 <betehess> ... and give to IETF
15:22:52 <betehess> Arnaud: he asked several times people to give feedback
15:22:58 <betehess> ... it's in our interest to support it
15:23:07 <betehess> ... we also have dependeency on it
15:23:32 <betehess> ... better sooner than later
15:23:38 <betehess> ... let's start with the issues
15:23:54 <betehess> ... we've had plenty of discussions on these issues already
15:24:12 <betehess> ... I want to limit conversations and vote directly
15:24:20 <betehess> ... to know where people stand
15:24:32 <betehess> ... so let's try
15:24:49 <betehess> ... start with issue-92
15:25:07 <roger> http://www.w3.org/2012/ldp/track/issues/92
15:25:07 <betehess> ... last it was proposed, only one objection from Henry but everybody else agreed
15:25:14 <betehess> TOPIC: ISSUE-92
15:25:21 <Arnaud> PROPOSED: Close ISSUE-92 by changing rel=type to rel=profile for client introspection of interaction model
15:25:27 <ericP> +1
15:25:30 <betehess> +1
15:25:34 <deiu> +1
15:25:41 <betehess> irc.w3.org
15:25:57 <SteveS> +1
15:26:06 <bblfish> bblfish has joined #ldp
15:26:08 <bblfish> ok
15:26:10 <sandro> -0.5
15:26:10 <TallTed> +1
15:26:22 <bblfish> -1
15:26:24 <nmihindu> +1
15:26:27 <roger> +0.5
15:26:48 <betehess> Arnaud: so the situation hasn't really change
15:27:02 <betehess> ... still mostly in favor
15:27:08 <Arnaud> PROPOSED: Close ISSUE-92 by keeping rel=type for client introspection of interaction model
15:27:17 <betehess> ... there is an alternative: keeping rel=type
15:27:17 <sandro> +1
15:27:18 <bblfish> +1
15:27:22 <ericP> -.5
15:27:25 <betehess> -.5
15:27:28 <deiu> 0
15:27:31 <SteveS> +0
15:27:38 <JohnArwe> -0.5 [holds nose]
15:27:48 <TallTed> -.75
15:27:51 <roger> +0.5
15:27:59 <ericP> hold your nose and give up on other interaction modes
15:28:08 <nmihindu> +0
15:28:12 <bblfish> nonsense, you can have other interaction modes
15:28:18 <Ashok> 0
15:28:30 <Arnaud> RESOLVED: Close ISSUE-92 by keeping rel=type for client introspection of interaction model
15:28:38 <betehess> Arnaud: thank you all
15:28:48 <betehess> ... I know it's not what the majority wanted
15:29:03 <TallTed> I think the option of multiple rel=type headers should be mentioned...
15:29:04 <betehess> ... Henry, you'll carry the burden of a decision nobody wanted
15:29:06 <bblfish> they'll thank me for it.
15:29:18 <betehess> TOPIC: ISSUE-89
15:29:28 <betehess> Arnaud: started with a conversation started by john
15:29:41 <betehess> ... we agreed to add ldp:contains
15:29:47 <betehess> ... question was: should it be materialized?
15:29:57 <betehess> ... john looked into using the Prefer header
15:30:12 <betehess> ... people had to read it and had enough time
15:30:33 <betehess> ... Prefer lets the client specify what triple it wants
15:30:50 <betehess> ... can request the server not to send certain triple with omit
15:31:02 <betehess> ... works at least with membership and containment triples
15:31:07 <Arnaud> PROPOSED: Close ISSUE-89 by adopting John's Proposal to materialize ldp:contains with a Prefer header to filter triples
15:31:12 <betehess> +1
15:31:13 <deiu> +1
15:31:16 <roger> +1
15:31:16 <JohnArwe> +1
15:31:19 <SteveS> +1
15:31:22 <TallTed> +1
15:31:25 <Ashok> +1
15:31:39 <nmihindu> +1
15:31:46 <ericP> +1
15:31:50 <sandro> +1
15:32:11 <bblfish> 0 did not have time to read it
15:32:19 <betehess> Arnaud: ouf !
15:32:19 <Arnaud> RESOLVED: Close ISSUE-89 by adopting John's Proposal to materialize ldp:contains with a Prefer header to filter triples
15:32:35 <betehess> Arnaud: now, other things related to that
15:32:51 <betehess> ... Alex proposed to improve the spec in an email
15:33:13 <betehess> ... by dropping the non-member-properties resource
15:33:24 <Arnaud> PROPOSED: Remove all mention of non-member-properties and  non-containment resources from the spec, the need is addressed by the  Prefer header.
15:33:33 <betehess> ... but you can to the "same" with the Prefer header
15:33:41 <betehess> ... you can achieve the same thing
15:33:50 <betehess> ... so this would make the spec simplier
15:34:13 <betehess> ... so it should be fine to remove it
15:34:14 <betehess> +1
15:34:23 <JohnArwe> +1
15:34:38 <deiu> +1
15:34:40 <roger> +1
15:34:50 <betehess> Arnaud: this is just house cleaning
15:34:51 <Ashok> +1
15:34:52 <ericP> +.5 (sounds good but i haven't thought hard)
15:34:59 <SteveS> +0.5 no strong preference
15:35:03 <nmihindu> +1
15:35:12 <TallTed> +0
15:35:19 <bblfish> +.5 sounds good but I have not thought hard. if it is just house cleaning then +1
15:35:20 <sandro> +0
15:36:12 <betehess> Arnaud: the spec today speaks about a special resource Link-ed from the container to avoid having some triples
15:36:21 <bblfish> q+
15:36:39 <betehess> JohnArwe: the server is always free to ignore the Prefer header
15:36:51 <Arnaud> ack bblfish
15:37:13 <betehess> bblfish: used to be some kind of relation to link to the resource?
15:38:02 <betehess> JohnArwe: instead of the server supplying the Link header for the subject of triples you're interested, now the client would ask to omit those triples with the Prefer header
15:38:11 <betehess> Arnaud: and you avoid one round-trip
15:38:23 <Arnaud> RESOLVED: Remove all mention of non-member-properties and  non-containment resources from the spec, the need is addressed by the  Prefer header.
15:38:27 <bblfish> http://www.w3.org/Protocols/HTTP/Methods.html
15:38:38 <betehess> bblfish: in early spec in HTTP, there was a SEARCH method
15:38:49 <betehess> ... we could add a SEARCH method
15:39:07 <betehess> Arnaud: don't know, but we can't afford to investigate in SEARCH
15:39:13 <betehess> ... maybe for LDP Next
15:39:28 <JohnArwe> @henry: looking at header reg, not seeing SEARCH
15:39:30 <betehess> ... on Friday, john proposed an extension for Prefer
15:39:45 <SteveS> thinks instead of SEARCH verb, people would just expose a SPARQL endpoint
15:39:48 <betehess> ... we could also allow the other way around
15:39:50 <bblfish> JohnArwe: it's at the end of http://www.w3.org/Protocols/HTTP/Methods.html
15:39:53 <Arnaud> PROPOSED: Add Prefer: include per John's addition proposal
15:39:58 <SteveS> +1
15:39:59 <betehess> ... where the client can ask triples to be included
15:40:33 <betehess> +0.5  sounds ok but didn't have time to do a deep review of the proposal
15:40:39 <TallTed> +1
15:40:42 <bblfish> Which issue are we looking at?
15:41:01 <deiu> +1
15:41:07 <SteveS> http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2014.01.27#ISSUE-89_-_Managed_Resources
15:41:11 <JohnArwe> http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jan/0124.html is the link from the agenda
15:41:11 <betehess> ... still related to issue 89
15:41:51 <nmihindu> +1
15:42:52 <betehess> Arnaud: we this, we'd have 2 preferences, omit and include, both dual
15:42:59 <JohnArwe> +0.5 (merely because it's not bare-minimum ... LDP could live with omit only; but I agree with the view that it's more natural for clients)
15:43:28 <betehess> roger: too bad we can't reuse URL for the preferences in the Prefer header
15:43:45 <betehess> JohnArwe: just following the syntax from the spec
15:43:49 <betehess> ... has to be a token
15:44:18 <betehess> ... one possibility would be to make it a URI, not sure if that would allowed by the BNF
15:44:26 <betehess> TallTed: we should check that
15:44:38 <betehess> Arnaud: yes, but that's orthogonal to this proposal
15:44:54 <betehess> TallTed: would be really good though
15:44:57 <bblfish> not sure of this as of the other, since I had not read it carefully
15:45:05 <betehess> Arnaud: I'm stopping you from that to happen
15:45:09 <JohnArwe> @Ted, would your pref for URI be met by the qname syntactic form?
15:45:11 <Arnaud> RESOLVED: Add Prefer: include per John's addition proposal
15:45:11 <betehess> ... would need a proposal
15:45:11 <roger> +1
15:45:26 <betehess> ... who wants to take the action?
15:45:35 <betehess> ... maybe TallTed?
15:45:45 <betehess> TallTed: ok, we'll look into it
15:46:21 <betehess> ACTION: Arnaud to investigate the use of URIs with the Prefer header
15:46:21 <trackbot> Created ACTION-129 - Investigate the use of uris with the prefer header [on Arnaud Le Hors - due 2014-02-03].
15:47:06 <JohnArwe> @ted: http://tools.ietf.org/html/draft-snell-http-prefer-18
15:47:20 <JohnArwe> the BNF refers back to bis however
15:47:20 <betehess> Arnaud: ok, now, more house cleaning
15:47:22 <Arnaud> PROPOSED: Get rid of ldp:created which is subsumed by ldp:contains
15:47:44 <betehess> ... we have ldp:created for historical reasons
15:48:02 <betehess> ... now we have agreed to have ldp:contains
15:48:15 <betehess> ... still didn't take time to get rid of ldp:created
15:48:22 <bblfish> +1
15:48:23 <JohnArwe> ...that's why Prefer is still a draft w/o an RFC #, the normative reference on bis queues it behind bis on the IETF editor's queue.
15:48:28 <betehess> ... so ldp:created is now obsolete
15:48:42 <deiu> +1
15:48:48 <betehess> +1
15:48:50 <JohnArwe> +1
15:48:59 <TallTed> +1
15:49:00 <nmihindu> +1
15:49:04 <SteveS> +1
15:49:14 <ericP> +1
15:49:15 <roger> +1
15:49:24 <Arnaud> RESOLVED: Get rid of ldp:created which is subsumed by ldp:contains
15:49:59 <betehess> Arnaud: looking at leftovers re: issues
15:50:03 <betehess> TOPIC: ISSUE-86
15:50:08 <JohnArwe> "Ding dong, the witch-ssue is dead"
15:50:24 <Arnaud> PROPOSED: Close ISSUE-86 doing nothing
15:50:32 <betehess> Arnaud: I think we can now just close this one easily
15:50:36 <bblfish> q+
15:50:54 <betehess> Arnaud: now we have a new term: containment
15:51:01 <betehess> ... different from membership
15:51:11 <betehess> ... the editors will reflect that when they have time
15:51:17 <Arnaud> ack bblfish
15:51:38 <betehess> bblfish: say you keep membership triple, now you don't have membershipXXX anymore
15:51:45 <betehess> ... suppose it's ok to keep it
15:51:53 <betehess> ... but you have problem with other relations
15:52:00 <betehess> ... not in sync with membership triples
15:52:24 <betehess> Arnaud: ah, talking about the name of rhte predicates
15:52:33 <JohnArwe> s/rthe/the/
15:52:48 <betehess> ... I understand, but would be a different issue
15:53:21 <betehess> I would let the editors free to propose changes during their rewriting
15:53:37 <SteveS> betehess, I was going to suggest the same thing
15:53:59 <betehess> Arnaud: ok, still, I think can close issue-86
15:54:15 <betehess> ... but recognize Henry's point
15:54:30 <bblfish> fine
15:54:32 <betehess> ... lets the editors make proposal for new names
15:55:06 <TallTed> regretfully, I think we do need another round of naming for the membership predicates, given where we've settled with the model (ldp:contains + ldp:members) ... but I do think that's distinct from 86
15:55:28 <Arnaud> PROPOSED: Close ISSUE-86 doing nothing
15:55:30 <bblfish> +1
15:55:30 <SteveS> +1
15:55:31 <betehess> +1
15:55:31 <deiu> +1
15:55:31 <roger> +1
15:55:34 <TallTed> +1
15:55:35 <nmihindu> +1
15:55:35 <JohnArwe> +1
15:55:37 <ericP> +1
15:55:48 <Arnaud> RESOLVED: Close ISSUE-86 doing nothing
15:56:35 <betehess> Arnaud: I don't want to have 5 proposals for new names, so I'll let the editors choose
15:56:43 <betehess> ... let's have them fight together
15:56:51 <SteveS> Editors were part of the original discussion on names and where we landed, we can use that same feedback again
15:57:02 <betehess> TOPIC: ISSUE-93
15:57:15 <bblfish> Issue-93
15:57:15 <trackbot> Issue-93 -- Accept and Auth -- raised
15:57:15 <trackbot> http://www.w3.org/2012/ldp/track/issues/93
15:57:41 <betehess> Arnaud: was raised by bblfish
15:57:55 <betehess> ... might be expensive to determine what's really allowed
15:58:02 <betehess> ... and the client might not even care
15:58:21 <bblfish> q+
15:58:34 <betehess> ... and we don't touch on Authorization, Authentication, etc.
15:58:35 <betehess> ... so I don't think we should discuss that today
15:58:46 <betehess> ... so the proposal is to remove a section in the spec
15:58:52 <Arnaud> ack bblfish
15:58:53 <betehess> ... and we completely rely on HTTP
15:59:12 <betehess> bblfish: I tried to do something like that with WebACL
15:59:19 <betehess> ... using OPTIONS
15:59:43 <betehess> ... was interested in people's feedback on that
16:00:07 <betehess> Arnaud: the problem here is for the client to ask the server "what can I do?"
16:00:19 <betehess> ... and depending on authorization, it could be different
16:00:31 <betehess> ... so it can set the wrong expectation
16:01:00 <SteveS> should be clear, it is not the Accept header but the Allow header
16:01:07 <betehess> ... so it can be expensive
16:01:14 <betehess> non-issue for me
16:01:52 <SteveS> q+
16:01:52 <betehess> ... as always, it comes down on where you put the burden
16:01:58 <betehess> ... can be server or client
16:02:12 <bblfish> I am ok with removing the HEAD/GET Allow. Just wondering if clients can rely on the server's setting the Allow: headers
16:02:17 <betehess> ... also, the server is free to lie
16:02:24 <JohnArwe> I think clients will generally prefer responses that are as specific to its context as possible.  OTOH doing so can lead to perverse results; e.g. on some wikis, until you login you don't see an Edit button (b/c you're an unauthenticated client).  If a server said "GET/HEAD only" to an unauthenticated request, even though that's specific to the client's context that *does not* mean that the client could not "upgrade"
16:02:24 <JohnArwe>  or find new capabilities available if it changed context (e.g. became authenticated).
16:02:45 <betehess> TallTed: the client has to deal with failure in any case, so don't make it more complicated
16:02:50 <Arnaud> ack SteveS
16:02:53 <betehess> Arnaud: yes, agree
16:03:05 <betehess> SteveS: wanted some clarity on the statement
16:03:30 <betehess> ... it means that they are not rquried for GET/HEAD?
16:03:46 <betehess> ... so a SHOULD could be better there?
16:04:05 <Zakim> -ericP
16:04:06 <betehess> bblfish: I think the may on GET/HEAD is ok
16:04:28 <betehess> ... if servers don't implement it correctly, then you can't rely on it anymore
16:04:42 <SteveS> "4.3.2 LDPR servers must support the HTTP response headers defined in section 4.9 ."
16:05:29 <betehess> JohnArwe: if you're un-authenticated, and you're trying to do stuff, then you can expect to be limited
16:05:52 <betehess> TallTed: then if you don't see the OPTIONS, then how do you know it's supported?
16:05:58 <bblfish> q+
16:06:34 <betehess> JohnArwe: I know security people and for them, if you don't try to do something, you don't need if you can actually do it
16:06:37 <Arnaud> ack bblfish
16:07:01 <JohnArwe> basically there are things pulling a server to respond in each direction
16:07:04 <betehess> bblfish: I think JohnArwe and TallTed are disagreeing
16:07:23 <betehess> ... have a feeling there is some unclarity there
16:07:43 <betehess> ... is OPSTION what I can do now, or if I'm authenticated?
16:07:55 <betehess> ... depending on answer, we may not need Allow header
16:08:29 <betehess> ... so for me, it should tell you what you're allowed to do depending on if you're authenticated or not
16:08:43 <betehess> Arnaud: we're not changing http OPTION
16:09:23 <betehess> ... so the proposal was just to remove section @@@
16:09:39 <betehess> s/@@@/4.3.2/
16:09:59 <betehess> ... and Henry thinks we can use a SHOULD instead
16:10:00 <bblfish> what is 4.3.2 now?
16:10:12 <betehess> s/Henry/SteveS/
16:10:16 <Arnaud> http://www.w3.org/TR/2013/WD-ldp-20130730/#ldpr-4_3_2
16:10:33 <Arnaud> 4.3.2 LDPR servers MUST support the HTTP response headers defined in  		section 4.9 .
16:10:35 <betehess> Arnaud: that is a stable link to the section in question
16:10:56 <bblfish> +1 I agree with Arnaud that this is too strong for GET/HEAD
16:10:58 <JohnArwe> ...and 4.9 in same doc says...
16:10:58 <JohnArwe> 4.9 HTTP OPTIONS
16:10:58 <JohnArwe> This specification imposes the following new requirements on HTTP OPTIONS for LDPRs beyond those in [HTTP11]. Other sections of this specification, for example PATCH, Accept-Post and Paging, add other requirements on OPTIONS responses.
16:10:58 <JohnArwe> 4.9.1 LDPR servers MUST support the HTTP OPTIONS method.
16:10:58 <JohnArwe> 4.9.2 LDPR servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow.
16:10:59 <betehess> ... several possibilities
16:11:04 <betehess> ... we could do nothing
16:12:04 <betehess> ... soften 4.3.2 from MUST to SHOULD
16:12:12 <bblfish> It is odd that LDPR MUST Support. It sounds like it says one has to have Allow
16:12:15 <betehess> ... remove 4.3.2 altogether
16:12:30 <betehess> ... (3 possibilities)
16:13:42 <betehess> Arnaud: also, I think we used it in one of tim's comments
16:13:44 <bblfish> q+
16:14:02 <Arnaud> ack bblfish
16:14:02 <betehess> SteveS: and he wanted to have as many MUST as possible
16:14:56 <betehess> bblfish: if you have an edit button on a webpage, then the client would do an extra round trip to know if it's editable
16:15:16 <betehess> Arnaud: not the page how it works today
16:15:24 <deiu> q+
16:15:31 <betehess> s/page/way/
16:15:32 <Arnaud> ack deiu
16:16:02 <betehess> deiu: from my dev point-of-view, would be interested to have some kind of option for when you do the first request
16:16:10 <betehess> ... so that you don't need to do it later
16:16:24 <bblfish> Deiu it's the Allow header not Accept header
16:16:59 <betehess> Arnaud: yes, we want to avoid having to do OPTION all the time
16:17:06 <betehess> ... maybe it's a mistake removing it
16:17:29 <betehess> bblfish: it is a bit expensive to implement, but not a big problem
16:17:46 <deiu> q+
16:17:49 <betehess> Arnaud: also the spec does not speak about auth*
16:18:14 <betehess> sandro: I understand it as a static field
16:18:41 <Arnaud> http://www.w3.org/TR/2013/WD-ldp-20130730/#ldpr-HTTP_OPTIONS
16:18:48 <betehess> bblfish: it sounds as if it was for that specific request
16:18:52 <Arnaud> 4.9.2 LDPR servers MUST indicate their support for HTTP Methods by 		responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP 		Method tokens in the HTTP response header Allow.
16:19:01 <JohnArwe> This feels like a case for Prefer, honestly ... if the client's intent "potentially includes" update, then it might ask for specificity.  Since MANY clients are not interested in update (we usually use a RoT 10:1 read:write), and ErikW pointed out it's often a losing proposition if the computation is expensive.
16:19:20 <betehess> ... then you could always return everything and people would realize later they can't do the operation
16:19:22 <SteveS> I wonder if this guidance is better for say, our guidance doc?
16:19:24 <deiu> q-
16:20:09 <betehess> Arnaud: today, the section is 4.9.2
16:20:24 <betehess> ... just pasted current wording
16:20:52 <betehess> sandro: uncertainty makes me nervous. would like to see a test case
16:21:12 <betehess> Arnaud: as you said earlier, a static approach would make you compliant
16:21:19 <betehess> ... question is whether you expect more
16:21:26 <betehess> sandro: depends on the use-case
16:21:38 <SteveS> q+
16:21:42 <betehess> Arnaud: we would have to add more requirements
16:21:49 <betehess> ... don't know what to put at risk
16:22:11 <betehess> sandro: Henry may not be the only one with those expectations
16:22:21 <Arnaud> ack SteveS
16:22:28 <bblfish> I was arguing if the point of Allow is to avoid clients doing a round trip,  then returning Allow: PUT, ... which is never related to the authentication level, then all servers will be publishing this info, and the client will have to do a few more round trips anyway. ( Say that we follow link acl that requires a lot more calls )
16:22:39 <betehess> SteveS: wanted to bring up the possibility to say something in the guidelines doc
16:23:06 <betehess> ... or we could create variants of 4.9.2
16:23:29 <betehess> ... depending on what the server wants to support
16:23:51 <betehess> Arnaud: this convinced me that at most, we should do nothing
16:23:55 <bblfish> deiu: it's the Allow header
16:24:05 <deiu> sorry, the Allow header
16:24:09 <betehess> ... people should make concrete proposals
16:24:20 <roger> I'm heading off - I think we resolved some thorny issues today and made good progress.
16:24:29 <Zakim> -Roger
16:24:55 <betehess> bblfish: we could ask TimBL what he thinks about it
16:25:01 <betehess> Arnaud: I want to close this now
16:25:15 <betehess> ... but I'm happy to investigate further
16:25:25 <bblfish> q+
16:25:29 <betehess> ... is that acceptable?
16:25:33 <Arnaud> ack bblfish
16:25:45 <betehess> bblfish: what's the issue with keeping it open one more week?
16:25:51 <betehess> ... would save time
16:26:09 <betehess> ... I'm implementing it and it's kinda important
16:26:23 <betehess> ... people reading the text don't know what they have to do with it
16:26:52 <betehess> Arnaud: the difference is that if we close it, it means that if nobody does anything, we'd have a default decision
16:27:06 <betehess> ... it's adminitrative
16:27:07 <SteveS> an action on someone to do something before next week?
16:27:16 <betehess> sandro: is somebody willing to take an action?
16:27:23 <betehess> Arnaud: good point
16:27:23 <JohnArwe> fwiw, the "support" word is in HTTP Allow's definition itself.  we're not causing any new problems (nor are we solving any) by re-using the word.
16:27:35 <betehess> ... if not, we could close it now
16:28:20 <SteveS> perhaps send to some http-discuss list?
16:28:37 <betehess> Arnaud: we made good progress, we have this issue pending
16:28:44 <betehess> ... let's let it in this state
16:28:49 <betehess> ... and discuss it next week
16:29:01 <betehess> ... I'm glad we went though almost everything
16:29:08 <betehess> ... hopefully we can get through this
16:29:16 <betehess> ... anything else before we close?
16:29:17 <JohnArwe> q+
16:29:45 <Arnaud> ack JohnArwe
16:29:48 <betehess> ... we'll have other things to discuss about: guidelines, test suites, etc.
16:29:54 <betehess> JohnArwe: re: f2f
16:30:02 <betehess> ... we may want to set the date
16:30:23 <Zakim> +EricP
16:30:31 <betehess> Arnaud: don't know how strict the w3c is about setting this date
16:30:36 <betehess> ... let's close on this
16:30:40 <Zakim> -Ashok_Malhotra
16:30:41 <Zakim> -JohnArwe
16:30:43 <Zakim> -bblfish
16:30:44 <Zakim> -Andrei
16:30:45 <Zakim> -nmihindu
16:30:48 <Zakim> -SteveS
16:30:49 <Zakim> -Arnaud
16:30:51 <Zakim> -TallTed
16:30:59 <Zakim> -EricP
16:31:31 <Zakim> -Sandro
16:31:33 <Zakim> SW_LDP()10:00AM has ended
16:31:33 <Zakim> Attendees were Arnaud, Ashok_Malhotra, JohnArwe, SteveS, Andrei, Alexandre, TallTed, Roger, ericP, Sandro, nmihindu, bblfish
16:35:39 <Arnaud> trackbot, end meeting
16:35:39 <trackbot> Zakim, list attendees
16:35:39 <Zakim> sorry, trackbot, I don't know what conference this is
16:35:47 <trackbot> RRSAgent, please draft minutes
16:35:47 <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/27-ldp-minutes.html trackbot
16:35:48 <trackbot> RRSAgent, bye
16:35:48 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2014/01/27-ldp-actions.rdf :
16:35:48 <RRSAgent> ACTION: Arnaud to investigate the use of URIs with the Prefer header [1]
16:35:48 <RRSAgent>   recorded in http://www.w3.org/2014/01/27-ldp-irc#T15-46-21