<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

ISSUE-92

<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.

ISSUE-89

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

ISSUE-86

<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

ISSUE-93

<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