See also: IRC log
<trackbot> Date: 27 January 2014
<JohnArwe> zakim seems under the weather today
<JohnArwe> ...just dropped me w/o asking for a code, but second try worked
<scribe> scribe: Alexandre
<scribe> scribenick: betehess
Arnaud: last week, because of not
enough people on the call, we had an informal call
... let's approve the minute from last meeting, 2 weeks
ago
... anybody looked at them?
<SteveS> look fine to me
Arnaud: ok let's approve
... next meeting is next week
... Feb 3rd
I guess you can close mine
Arnaud: what about actions?
... anybody claiming victory?
... we can close ACTION-128
... wanted to spend a minute speaking about timeline
... currrent charter expires at the end of May
... we should try having a PR before then
... think it's possible
... even if we close all issues today, still hard to get
there
... can't afford to discuss new things
... people need to accept that the spec won't be perfect
... it's better if we don't have to re-charter
... so we have to prove to the w3c management that we're ready
to deliver
... also depends on the editors, but there are quite a few
changes so it won't be done in one week
... one big unknown: what we get during 2nd LC
... we may have significant comments and go to another LC
... requires negociations with the commenters
... so the timeline I drafted is an idea
... time will tell us
... we've had a lot of comments after 1rst LC
... the time for next f2f could be in 2 months from now
... would give us a chance to meet after the LC
... just wanted to tell people what to expect
sandro: agree with general analysis, was wondering about tracking implementations/test suite for CR
Arnaud: there is a wiki page tracking all that
<SteveS> http://www.w3.org/wiki/LDP_Implementations
Arnaud: don't know how accurate
it is
... what's not clear is how long it will take for people to
refelct last changes
ericP: what you have to do is proving that your implementation do X, Y and Z
sandro: the test suite is just human readable
ericP: correct
<SteveS> Info on "Testing" http://www.w3.org/2012/ldp/wiki/Testing
Arnaud: Raul has been trying to do that but couldn't keep up with all the changes (nobody can blame him)
sandro: maybe somebody will share his code
ericP: problem is for generic triplestores
Arnaud: yes, there can be domain
specific constraints
... will be mainly based on claims from people
ericP: we do the same in other WGs, when we give them the test suites
sandro: we can skip CR if we meet those criterias
ericP: even better if we have that for LC
Arnaud: let's move on with the
agenda
... Accept-POST
... written by Erik Wilde
JohnArwe: erik will do some
cleanup on the draft
... ask people with implementations, prototypes, intentions, to
tell him
... to have an implementation report
... and give to IETF
Arnaud: he asked several times
people to give feedback
... it's in our interest to support it
... we also have dependeency on it
... better sooner than later
... let's start with the issues
... we've had plenty of discussions on these issues
already
... I want to limit conversations and vote directly
... to know where people stand
... so let's try
... start with issue-92
<roger> http://www.w3.org/2012/ldp/track/issues/92
Arnaud: last it was proposed, only one objection from Henry but everybody else agreed
<Arnaud> PROPOSED: Close ISSUE-92 by changing rel=type to rel=profile for client introspection of interaction model
<ericP> +1
+1
<deiu> +1
irc.w3.org
<SteveS> +1
<bblfish> ok
<sandro> -0.5
<TallTed> +1
<bblfish> -1
<nmihindu> +1
<roger> +0.5
Arnaud: so the situation hasn't
really change
... still mostly in favor
<Arnaud> PROPOSED: Close ISSUE-92 by keeping rel=type for client introspection of interaction model
Arnaud: there is an alternative: keeping rel=type
<sandro> +1
<bblfish> +1
<ericP> -.5
-.5
<deiu> 0
<SteveS> +0
<JohnArwe> -0.5 [holds nose]
<TallTed> -.75
<roger> +0.5
<ericP> hold your nose and give up on other interaction modes
<nmihindu> +0
<bblfish> nonsense, you can have other interaction modes
<Ashok> 0
<Arnaud> RESOLVED: Close ISSUE-92 by keeping rel=type for client introspection of interaction model
Arnaud: thank you all
... I know it's not what the majority wanted
<TallTed> I think the option of multiple rel=type headers should be mentioned...
Arnaud: Henry, you'll carry the burden of a decision nobody wanted
<bblfish> they'll thank me for it.
Arnaud: started with a
conversation started by john
... we agreed to add ldp:contains
... question was: should it be materialized?
... john looked into using the Prefer header
... people had to read it and had enough time
... Prefer lets the client specify what triple it wants
... can request the server not to send certain triple with
omit
... works at least with membership and containment triples
<Arnaud> PROPOSED: Close ISSUE-89 by adopting John's Proposal to materialize ldp:contains with a Prefer header to filter triples
+1
<deiu> +1
<roger> +1
<JohnArwe> +1
<SteveS> +1
<TallTed> +1
<Ashok> +1
<nmihindu> +1
<ericP> +1
<sandro> +1
<bblfish> 0 did not have time to read it
Arnaud: ouf !
<Arnaud> RESOLVED: Close ISSUE-89 by adopting John's Proposal to materialize ldp:contains with a Prefer header to filter triples
Arnaud: now, other things related
to that
... Alex proposed to improve the spec in an email
... by dropping the non-member-properties resource
<Arnaud> PROPOSED: Remove all mention of non-member-properties and non-containment resources from the spec, the need is addressed by the Prefer header.
Arnaud: but you can to the "same"
with the Prefer header
... you can achieve the same thing
... so this would make the spec simplier
... so it should be fine to remove it
+1
<JohnArwe> +1
<deiu> +1
<roger> +1
Arnaud: this is just house cleaning
<Ashok> +1
<ericP> +.5 (sounds good but i haven't thought hard)
<SteveS> +0.5 no strong preference
<nmihindu> +1
<TallTed> +0
<bblfish> +.5 sounds good but I have not thought hard. if it is just house cleaning then +1
<sandro> +0
Arnaud: the spec today speaks about a special resource Link-ed from the container to avoid having some triples
JohnArwe: the server is always free to ignore the Prefer header
bblfish: used to be some kind of relation to link to the resource?
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
Arnaud: and you avoid one round-trip
<Arnaud> RESOLVED: Remove all mention of non-member-properties and non-containment resources from the spec, the need is addressed by the Prefer header.
<bblfish> http://www.w3.org/Protocols/HTTP/Methods.html
bblfish: in early spec in HTTP,
there was a SEARCH method
... we could add a SEARCH method
Arnaud: don't know, but we can't
afford to investigate in SEARCH
... maybe for LDP Next
<JohnArwe> @henry: looking at header reg, not seeing SEARCH
Arnaud: on Friday, john proposed an extension for Prefer
<SteveS> thinks instead of SEARCH verb, people would just expose a SPARQL endpoint
Arnaud: we could also allow the other way around
<bblfish> JohnArwe: it's at the end of http://www.w3.org/Protocols/HTTP/Methods.html
<Arnaud> PROPOSED: Add Prefer: include per John's addition proposal
<SteveS> +1
Arnaud: where the client can ask triples to be included
+0.5 sounds ok but didn't have time to do a deep review of the proposal
<TallTed> +1
<bblfish> Which issue are we looking at?
<deiu> +1
<SteveS> http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2014.01.27#ISSUE-89_-_Managed_Resources
<JohnArwe> http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jan/0124.html is the link from the agenda
scribe: still related to issue 89
<nmihindu> +1
Arnaud: we this, we'd have 2 preferences, omit and include, both dual
<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)
roger: too bad we can't reuse URL for the preferences in the Prefer header
JohnArwe: just following the
syntax from the spec
... has to be a token
... one possibility would be to make it a URI, not sure if that
would allowed by the BNF
TallTed: we should check that
Arnaud: yes, but that's orthogonal to this proposal
TallTed: would be really good though
<bblfish> not sure of this as of the other, since I had not read it carefully
Arnaud: I'm stopping you from that to happen
<JohnArwe> @Ted, would your pref for URI be met by the qname syntactic form?
<Arnaud> RESOLVED: Add Prefer: include per John's addition proposal
Arnaud: would need a proposal
<roger> +1
Arnaud: who wants to take the
action?
... maybe TallTed?
TallTed: ok, we'll look into it
<scribe> ACTION: Arnaud to investigate the use of URIs with the Prefer header [recorded in http://www.w3.org/2014/01/27-ldp-minutes.html#action01]
<trackbot> Created ACTION-129 - Investigate the use of uris with the prefer header [on Arnaud Le Hors - due 2014-02-03].
<JohnArwe> @ted: http://tools.ietf.org/html/draft-snell-http-prefer-18
<JohnArwe> the BNF refers back to bis however
Arnaud: ok, now, more house cleaning
<Arnaud> PROPOSED: Get rid of ldp:created which is subsumed by ldp:contains
Arnaud: we have ldp:created for
historical reasons
... now we have agreed to have ldp:contains
... still didn't take time to get rid of ldp:created
<bblfish> +1
<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.
Arnaud: so ldp:created is now obsolete
<deiu> +1
+1
<JohnArwe> +1
<TallTed> +1
<nmihindu> +1
<SteveS> +1
<ericP> +1
<roger> +1
<Arnaud> RESOLVED: Get rid of ldp:created which is subsumed by ldp:contains
Arnaud: looking at leftovers re: issues
<JohnArwe> "Ding dong, the witch-ssue is dead"
<Arnaud> PROPOSED: Close ISSUE-86 doing nothing
Arnaud: I think we can now just
close this one easily
... now we have a new term: containment
... different from membership
... the editors will reflect that when they have time
bblfish: say you keep membership
triple, now you don't have membershipXXX anymore
... suppose it's ok to keep it
... but you have problem with other relations
... not in sync with membership triples
Arnaud: ah, talking about the name of rhte predicates
<JohnArwe> s/rthe/the/
Arnaud: I understand, but would be a different issue
I would let the editors free to propose changes during their rewriting
<SteveS> betehess, I was going to suggest the same thing
Arnaud: ok, still, I think can
close issue-86
... but recognize Henry's point
<bblfish> fine
Arnaud: lets the editors make proposal for new names
<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
<Arnaud> PROPOSED: Close ISSUE-86 doing nothing
<bblfish> +1
<SteveS> +1
+1
<deiu> +1
<roger> +1
<TallTed> +1
<nmihindu> +1
<JohnArwe> +1
<ericP> +1
<Arnaud> RESOLVED: Close ISSUE-86 doing nothing
Arnaud: I don't want to have 5
proposals for new names, so I'll let the editors choose
... let's have them fight together
<SteveS> Editors were part of the original discussion on names and where we landed, we can use that same feedback again
<bblfish> Issue-93
<trackbot> Issue-93 -- Accept and Auth -- raised
<trackbot> http://www.w3.org/2012/ldp/track/issues/93
Arnaud: was raised by
bblfish
... might be expensive to determine what's really allowed
... and the client might not even care
... and we don't touch on Authorization, Authentication,
etc.
... so I don't think we should discuss that today
... so the proposal is to remove a section in the spec
... and we completely rely on HTTP
bblfish: I tried to do something
like that with WebACL
... using OPTIONS
... was interested in people's feedback on that
Arnaud: the problem here is for
the client to ask the server "what can I do?"
... and depending on authorization, it could be different
... so it can set the wrong expectation
<SteveS> should be clear, it is not the Accept header but the Allow header
Arnaud: so it can be expensive
non-issue for me
scribe: as always, it comes down
on where you put the burden
... can be server or client
<bblfish> I am ok with removing the HEAD/GET Allow. Just wondering if clients can rely on the server's setting the Allow: headers
scribe: also, the server is free to lie
<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"
<JohnArwe> or find new capabilities available if it changed context (e.g. became authenticated).
TallTed: the client has to deal with failure in any case, so don't make it more complicated
Arnaud: yes, agree
SteveS: wanted some clarity on
the statement
... it means that they are not rquried for GET/HEAD?
... so a SHOULD could be better there?
bblfish: I think the may on
GET/HEAD is ok
... if servers don't implement it correctly, then you can't
rely on it anymore
<SteveS> "4.3.2 LDPR servers must support the HTTP response headers defined in section 4.9 ."
JohnArwe: if you're un-authenticated, and you're trying to do stuff, then you can expect to be limited
TallTed: then if you don't see the OPTIONS, then how do you know it's supported?
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
<JohnArwe> basically there are things pulling a server to respond in each direction
bblfish: I think JohnArwe and
TallTed are disagreeing
... have a feeling there is some unclarity there
... is OPSTION what I can do now, or if I'm
authenticated?
... depending on answer, we may not need Allow header
... so for me, it should tell you what you're allowed to do
depending on if you're authenticated or not
Arnaud: we're not changing http
OPTION
... so the proposal was just to remove section 4.3.2
... and SteveS thinks we can use a SHOULD instead
<bblfish> what is 4.3.2 now?
<Arnaud> http://www.w3.org/TR/2013/WD-ldp-20130730/#ldpr-4_3_2
<Arnaud> 4.3.2 LDPR servers MUST support the HTTP response headers defined in section 4.9 .
Arnaud: that is a stable link to the section in question
<bblfish> +1 I agree with Arnaud that this is too strong for GET/HEAD
<JohnArwe> ...and 4.9 in same doc says...
<JohnArwe> 4.9 HTTP OPTIONS
<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.
<JohnArwe> 4.9.1 LDPR servers MUST support the HTTP OPTIONS method.
<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.
Arnaud: several
possibilities
... we could do nothing
... soften 4.3.2 from MUST to SHOULD
<bblfish> It is odd that LDPR MUST Support. It sounds like it says one has to have Allow
Arnaud: remove 4.3.2
altogether
... (3 possibilities)
... also, I think we used it in one of tim's comments
SteveS: and he wanted to have as many MUST as possible
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
Arnaud: not the way how it works today
deiu: from my dev point-of-view,
would be interested to have some kind of option for when you do
the first request
... so that you don't need to do it later
<bblfish> Deiu it's the Allow header not Accept header
Arnaud: yes, we want to avoid
having to do OPTION all the time
... maybe it's a mistake removing it
bblfish: it is a bit expensive to implement, but not a big problem
Arnaud: also the spec does not speak about auth*
sandro: I understand it as a static field
<Arnaud> http://www.w3.org/TR/2013/WD-ldp-20130730/#ldpr-HTTP_OPTIONS
bblfish: it sounds as if it was for that specific request
<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.
<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.
bblfish: then you could always return everything and people would realize later they can't do the operation
<SteveS> I wonder if this guidance is better for say, our guidance doc?
Arnaud: today, the section is
4.9.2
... just pasted current wording
sandro: uncertainty makes me nervous. would like to see a test case
Arnaud: as you said earlier, a
static approach would make you compliant
... question is whether you expect more
sandro: depends on the use-case
Arnaud: we would have to add more
requirements
... don't know what to put at risk
sandro: Henry may not be the only one with those expectations
<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 )
SteveS: wanted to bring up the
possibility to say something in the guidelines doc
... or we could create variants of 4.9.2
... depending on what the server wants to support
Arnaud: this convinced me that at most, we should do nothing
<bblfish> deiu: it's the Allow header
<deiu> sorry, the Allow header
Arnaud: people should make concrete proposals
<roger> I'm heading off - I think we resolved some thorny issues today and made good progress.
bblfish: we could ask TimBL what he thinks about it
Arnaud: I want to close this
now
... but I'm happy to investigate further
... is that acceptable?
bblfish: what's the issue with
keeping it open one more week?
... would save time
... I'm implementing it and it's kinda important
... people reading the text don't know what they have to do
with it
Arnaud: the difference is that if
we close it, it means that if nobody does anything, we'd have a
default decision
... it's adminitrative
<SteveS> an action on someone to do something before next week?
sandro: is somebody willing to take an action?
Arnaud: good point
<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.
Arnaud: if not, we could close it now
<SteveS> perhaps send to some http-discuss list?
Arnaud: we made good progress, we
have this issue pending
... let's let it in this state
... and discuss it next week
... I'm glad we went though almost everything
... hopefully we can get through this
... anything else before we close?
... we'll have other things to discuss about: guidelines, test
suites, etc.
JohnArwe: re: f2f
... we may want to set the date
Arnaud: don't know how strict the
w3c is about setting this date
... let's close on this
<Arnaud> trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Juan/Raul/ FAILED: s/rthe/the/ Succeeded: s/@@@/4.3.2/ Succeeded: s/Henry/SteveS/ Succeeded: s/page/way/ Found Scribe: Alexandre Found ScribeNick: betehess Default Present: Arnaud, Ashok_Malhotra, JohnArwe, SteveS, Andrei, Alexandre, TallTed, Roger, ericP, Sandro, nmihindu, bblfish Present: Arnaud Ashok_Malhotra JohnArwe SteveS Andrei Alexandre TallTed Roger ericP Sandro nmihindu bblfish Regrets: cody WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 27 Jan 2014 Guessing minutes URL: http://www.w3.org/2014/01/27-ldp-minutes.html People with action items: arnaud[End of scribe.perl diagnostic output]