View source for LDP Next CG Meeting 2016-09-22

== Agenda ==

* Introduce activities / changes since last meeting (subject matter interest table, Slack channel) 
* Invite active participants to the Slack channel on-the-spot (if we missed anyone)
* Discuss If-Match and Weak ETags issue with a focus on defining a desired outcome: http://lists.w3.org/Archives/Public/public-ldpnext/2016Aug/0002.html
* Time permitting (although I don't think there will be); review interest table and discuss next subject matter (such as fetching constrained resources).
* Recap commitments and action items (if any)

== Meeting Outcomes ==

The team discussed and came to a better understanding of the "If-Match and Weak ETags issue".

Our assumption to date is that the LDP spec says that If-Match and ETags should be used as the mechanism for avoiding resource collisions. However, it then becomes necessary to follow that back to the specs upon which they are based, which state that you MUST use strong comparison (strong ETag, not weak). Community Group members (a lot being in the Fedora community), are concerned because it does not seem likely that strong, byte-per-byte sameness may be that common for an LDP. An example discussed is the fact that an RDFSource can be semantically the same, but triples may be in a different order.

In the following document, https://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0035.html, we found an interesting snippet where Pierre-Antoine Champin was speaking about this. He wrote:

I also think we should be clear about the rationale of using weak etags.

For example, something like:

The server MAY provide a strong etag (ref), but only if it can guarantee that the same graph will always be serialized the exact same way (byte-wise). This is not always the case, as the order of triples or blank node labels are not significant in RDF and may vary across serializations. If the server can not ensure that, the etags it provides MUST be weak etags (ref).

So, the issue is that the LDP 1.0 spec, as written (section 4.2.4.5) does not seem to be making a pragmatic recommendation for LDP.

An possible alternative such as using (`If-Unmodified-Since`) was proposed.

The team meeting and discussing this was small and many of the Fedora members were not available. As a result, we did not get to any concrete recommendation for a possible change. We did, however learn a lot more about the issue and found value in digesting and discussing it amongst those who attended (see meeting recording below). 

Aside from this issue, which has had the most "noise" lately, the following other priorities were identified (in order of importance to those who attended):

* Inline on GET
* Inline on POST
* Paging

The following action items were identified:

* Try to engage more members of the Fedora group to provide input and ideas to the "If-Match and Weak ETags issue"; maybe in light of this discussion, they'll have a little more to chew on.
* Put out a call to the CG for input/ideas on the 3 next listed topics above. (Cody will do soon)
* Work on establishing a GitHub repo under the W3C so that we can have issue tracking immediately, and collaborative report editing soon. We probably need to talk to Sandro for help with this. (Cody will follow up with him).

== Meeting Recording ==

* https://recordings.join.me/B9_cBr-EP0it_YKx4KknOA

== Chat Log ==

Sorry, but I did not scribe by naming the speakers and just sort of took some notes as best I could. So, these are comments coming from across the five attendees:

* Fedora community (some or many) have been using a set of RDF libraries written in Ruby. And there seems to be some concern that you’re not guaranteed to get triples in a certain order. So - you can have the same “semantic” representation of a resource, but not a byte-by-byte sameness.
* anarchivist (Mark M)  https://jira.duraspace.org/browse/FCREPO-2098
* https://wiki.duraspace.org/display/FF/Fedora+Repository+Home
* Also related: Fix ETag Handling, Issue #68, ruby-rdf/rdf-ldp, GitHub: https://github.com/ruby-rdf/rdf-ldp/issues/68
* We have a few problems with ETag handling: RFC 7232 sec. 3.1 requires us to use strong validation on If-Match, we use weak. Even our weak validation is incorrect; see RFC 7232 sec. 2.3.2. If we ... 
* from tom j on the same issue: >>> The restriction referred to in the email thread linked above was added in https://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-24. I'm unsure whether the LDP WG ever discussed this development. (edited)
* Here's some additional, albeit much more detailed, discussions from a Fedora tech call that led to TomJ's message to `public-ldpnext`: https://wiki.duraspace.org/display/FF/2016-08-11+-+Fedora+Tech+Meeting
* "We don’t have a real good sense of how widespread the problem is."
* Understandding 4.2.4.5 is not pragmatic guidance; hard to follow-through on with LDP - given that a resource can be semantically the same (but say, different order of triples).
* Previous LDP WG discussion: https://www.w3.org/2012/ldp/track/issues/10
* "Can a spec override another spec? We can write a non-normative section that describes these difficulties?"
* We think Tom’s "alternate" is suggesting that we replace the use of IF-MATCH/ETAG, not provide another alternative.
* Is there areas of the spec that are not specified, which when implemented (as it may be common to do so) would impede interoperability? Should we try to start listing such things as part of CG report?
* Recommended to start a Git repo for creating our report (once we agree on at least 1 thing that should go in the report); team seems to think this will be a more open way of editing (with pull requests)
* Suggested NEXT agenda items (in priority and AFTER we get somewhere with IF/MATCH or when we don't have the right people to discuss it)
** Inline on GET
** Inline on POST
** Paging
* ACTION ITEM: Put out a call to the CG for input/ideas on the topics above.
* Decided we’d like to start a GitHub for documents and issue tracking.
** ACTION ITEM: We probably need to talk to Sandro about this if we want to do it within the W3C GitHub acct.