IRC log of ldp on 2014-01-27

Timestamps are in UTC.

14:57:11 [RRSAgent]
RRSAgent has joined #ldp
14:57:11 [RRSAgent]
logging to
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]
15:00:56 [Zakim]
15:01:19 [JohnArwe]
JohnArwe has joined #ldp
15:01:28 [JohnArwe]
zakim seems under the weather today
15:01:51 [Zakim]
15:01:55 [JohnArwe]
...just dropped me w/o asking for a code, but second try worked
15:03:06 [Zakim]
15:03:24 [SteveS]
zakim, Steve_Speicher is me
15:03:24 [Zakim]
+SteveS; got it
15:04:27 [Zakim]
15:04:37 [betehess]
Zakim, Matt is Andrei
15:04:37 [Zakim]
+Andrei; got it
15:04:53 [Zakim]
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]
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]
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]
15:10:28 [betehess]
I guess you can close mine
15:10:30 [Zakim]
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]
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]
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]
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"
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]
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]
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]
15:25:07 [betehess]
... last it was proposed, only one objection from Henry but everybody else agreed
15:25:14 [betehess]
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]
15:25:30 [betehess]
15:25:34 [deiu]
15:25:41 [betehess]
15:25:57 [SteveS]
15:26:06 [bblfish]
bblfish has joined #ldp
15:26:08 [bblfish]
15:26:10 [sandro]
15:26:10 [TallTed]
15:26:22 [bblfish]
15:26:24 [nmihindu]
15:26:27 [roger]
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]
15:27:18 [bblfish]
15:27:22 [ericP]
15:27:25 [betehess]
15:27:28 [deiu]
15:27:31 [SteveS]
15:27:38 [JohnArwe]
-0.5 [holds nose]
15:27:48 [TallTed]
15:27:51 [roger]
15:27:59 [ericP]
hold your nose and give up on other interaction modes
15:28:08 [nmihindu]
15:28:12 [bblfish]
nonsense, you can have other interaction modes
15:28:18 [Ashok]
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]
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]
15:31:13 [deiu]
15:31:16 [roger]
15:31:16 [JohnArwe]
15:31:19 [SteveS]
15:31:22 [TallTed]
15:31:25 [Ashok]
15:31:39 [nmihindu]
15:31:46 [ericP]
15:31:50 [sandro]
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]
15:34:23 [JohnArwe]
15:34:38 [deiu]
15:34:40 [roger]
15:34:50 [betehess]
Arnaud: this is just house cleaning
15:34:51 [Ashok]
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]
15:35:12 [TallTed]
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]
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]
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]
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
15:39:53 [Arnaud]
PROPOSED: Add Prefer: include per John's addition proposal
15:39:58 [SteveS]
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]
15:40:42 [bblfish]
Which issue are we looking at?
15:41:01 [deiu]
15:41:07 [SteveS]
15:41:11 [JohnArwe] is the link from the agenda
15:41:11 [betehess]
... still related to issue 89
15:41:51 [nmihindu]
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]
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]
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]
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]
15:48:48 [betehess]
15:48:50 [JohnArwe]
15:48:59 [TallTed]
15:49:00 [nmihindu]
15:49:04 [SteveS]
15:49:14 [ericP]
15:49:15 [roger]
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]
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]
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]
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]
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]
15:55:30 [SteveS]
15:55:31 [betehess]
15:55:31 [deiu]
15:55:31 [roger]
15:55:34 [TallTed]
15:55:35 [nmihindu]
15:55:35 [JohnArwe]
15:55:37 [ericP]
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]
15:57:15 [bblfish]
15:57:15 [trackbot]
Issue-93 -- Accept and Auth -- raised
15:57:15 [trackbot]
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]
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]
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]
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]
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]
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]
16:10:16 [Arnaud]
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]
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]
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]
16:15:31 [betehess]
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]
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]
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]
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]
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]
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]
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]
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]
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]
16:30:41 [Zakim]
16:30:43 [Zakim]
16:30:44 [Zakim]
16:30:45 [Zakim]
16:30:48 [Zakim]
16:30:49 [Zakim]
16:30:51 [Zakim]
16:30:59 [Zakim]
16:31:31 [Zakim]
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 trackbot
16:35:48 [trackbot]
RRSAgent, bye
16:35:48 [RRSAgent]
I see 1 open action item saved in :
16:35:48 [RRSAgent]
ACTION: Arnaud to investigate the use of URIs with the Prefer header [1]
16:35:48 [RRSAgent]
recorded in