JSON-LD Working Group Telco — Minutes

Date: 2019-06-07

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Benjamin Young, Pierre-Antoine Champin, Ivan Herman, Ruben Taelman, Tim Cole, David Newbury, Adam Soroka, David I. Lehn

Regrets: Gregg Kellogg, Dave Longley, Simon Steyskal

Guests:

Chair: Rob Sanderson

Scribe(s): Tim Cole

Content:

1. Approve minutes of previous call

Proposed resolution: Approve minutes of the previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-31-json-ld (Rob Sanderson)

Benjamin Young: +1

Ruben Taelman: +1

Rob Sanderson: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

David Newbury: +1

Resolution #1: Approve minutes of the previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-31-json-ld

2. Announcements / Reminders

2.1. TPAC

Rob Sanderson: TPAC registration is open. Please remember to register before 21 June close to early registration
… this is earlier than usual because TPAC is in Sept
… any other announcements?

2.2. Horizontal Review

Ivan Herman: we really need to get the horizontal reviews done in a timely fashion
… don’t expect issues but reviewers will appreciate if we get to these early
… we need somebody for security and privacy
… privacy wants our person to attend IG call and gives an overview
… we would like people for horizontal reviews to volunteer asap

Rob Sanderson: happy to volunteer (depending on time) but would be good to have Greg and others help

Pierre-Antoine Champin: also happy to help but less comfortable about API

Ivan Herman: Rob should send email to privacy group asking time when they can fit us on their agenda
… probably Rob and pchampin for sure, Ivan and Greg as available
… same thing for security - they’ll come to us
… for accessibility we start with their questionnaire

Ivan Herman: https://w3c.github.io/apa/fast/checklist.html

Ivan Herman: once this is done then we contact them as next step

Rob Sanderson: one person will need to take lead on filling out questionnaire - others could be on irc to help
… so, we should ask Greg about availability when he gets back
… Rob and Pierre-Antoine will do best to make themselves available
… other volunteers would be appreciated.

2.3. I18N

Ivan Herman: we will need one more to work with internationalization
… the big issue we may have is ability to add base string direction
… (Rob should still contact soon to deal with any other issues)

Rob Sanderson: reference: https://github.com/w3c/json-ld-syntax/issues/11

Ivan Herman: with regard to string direction this is coming up with a lot of WGs and we have talked about it in this WG
… we should discuss next week when Greg is back and we’ve had a little more time to catch up on topic

Ivan Herman: -> https://w3c.github.io/rdf-dir-literal/ discussion on direction issue

Rob Sanderson: any other issues or announcements

3. Issues

Rob Sanderson: tried to pick issues for this week less related to API and more related to syntax and policy

3.1. Profile IRIs

Ivan Herman: https://github.com/w3c/json-ld-syntax/issues/170

Ivan Herman: one background - transition calls with WOT people
… they were interested in a profile for their own needs
… but what came up is what is policy with regard to what is said in W3C documents
… by default each WG has its own profile space (e.g., ns/jsonld…)
… and that’s it

Rob Sanderson: there are profile URIs (e.g., Web Annotation)
… if you don’t understand it, you must ignore it

Proposed resolution: Accept #170, with the clarification that processors MUST ignore IRIs that that they do not recognize, and that json-ld* IRIs are reserved for future WG use (Rob Sanderson)

Rob Sanderson: +1

Adam Soroka: +1

Tim Cole: +1

Ruben Taelman: +1

Ivan Herman: +1

Benjamin Young: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

David Newbury: +1

Resolution #2: Accept #170, with the clarification that processors MUST ignore IRIs that that they do not recognize, and that json-ld IRIs are reserved for future WG use*

Rob Sanderson: Action to implement this resolution is on pchampin or greg

Action #1: update syntax with issue #170 resolution (Pierre-Antoine Champin)

3.2. Compact IRIs and URI Schemes

Ivan Herman: https://github.com/w3c/json-ld-syntax/issues/177

Rob Sanderson: we discussed this a few weeks ago, but only to point of introducing the issue.
… hopefully people have thought about it
… the issue is that IRI schemes that don’t start with // are seen as compact IRIs
… e.g., icon:… is seen as a compact IRI not a full IRI
… we could define these as undefined (rather than a prefix)
… this approach adds a little security without banning all non // schemes

Ivan Herman: I don’t fully understand - so in your example in the issue, what’s the role of protected

Rob Sanderson: avoids someone stealing the meaning of prefix (e.g., mailto:)

Benjamin Young: the goal is to allow continued use of these kinds of IRI prefixes

Rob Sanderson: having it in the context seems a good solution since it allows you to specify only the scope where you use the scheme rather than everywhere

Benjamin Young: yes, it is good to scope this

Pierre-Antoine Champin: it seems to me the protected approach would not be very efficient
… I’m not sure I fully grasp the use cases, but it seems you still get around protected
… the only way to really protect against redirection of mailto: is to protect the individual properties (e.g., email)

Rob Sanderson: so you say that email values not to be expected

Pierre-Antoine Champin: not sure this requires anything additional since we already have prefix
… seems a matter of best practice

Ivan Herman: in the example you have two approaches nul and prefix=false

Rob Sanderson: probably prefix=false, this works well since we already have prefix

Ivan Herman: do we?

Rob Sanderson: issue 76

Rob Sanderson: ref;: https://github.com/w3c/json-ld-api/issues/76

Pierre-Antoine Champin: a more efficient protection would be { "email": { "@id": "http://example.org/emailAddress", "@type": "@id", "@protected": true, "@context": { "mailto": { "@prefix": false } } }

Rob Sanderson: proposal was made to add prefix with 3 allowed values (one of which would be false, as required by issue 177)
… the issue in doing this was that you need to have an @id, which is why we might still need @id null
… seems like we shouldn’t need that if prefix: false
… Pierre-Antoine, does prefix: false already sufficient?

Pierre-Antoine Champin: not sure

Ruben Taelman: doesn’t seem to work right now

Rob Sanderson: but maybe it protects against intentional mischief
… anyone willing to take action to verify that prefix: false does work or can be made to work?

Pierre-Antoine Champin: okay, put this action on me

Action #2: test if @prefix: false without @id works as expected (Pierre-Antoine Champin)

David I. Lehn: find it a little hard to understand the attack line here
… if we assume all contexts are a risk, seems a bigger problem
… protect should be more about extension and override

Rob Sanderson: we have run into this issue with regard to content being incorrectly expanded

Benjamin Young: not directly on point, but it feels like a lot of our issues have had to do with managing context intermingling
… we may need to zoom out a little
… while there are issues here it seems like its about trust of contexts, ownership of contexts, etc.
… this fragility that is still there is where we may have issues with security and privacy reviews
… I sometimes feel like we’re applying pressure to the wrong part of the ecosystem
… it’s not clear the role and motivation of the actors
… so maybe we need a broader view
… would not be an issue if you always trusted the context file you reference

Rob Sanderson: not certain about that. If you define mailto: you need to undefine it elsewhere in your instance

Benjamin Young: so this is partly about remixing within instance / context

Rob Sanderson: I think at least we need to determining how prefix: false works without @id or @id: null
… need to be able to treat these as resource IRI when you want to

Ivan Herman: I share bigbluehat’s concerns in a general way
… for this issue you are asking if prefix: false solves current issue
… since prefix is a 1.1 key, we need it to work as we want and so if it’s not working that way now, let’s make it work

Pierre-Antoine Champin: the questions becoming: is it possible (i.e. not over-complicated) to implement @prefix to work like this

Rob Sanderson: the action should allow us to do this

Pierre-Antoine Champin: i just realized during discussion we have already introduced redefining a term that looks like an IRI because no useful use case for doing this
… in a way this desire to limit prefixes that are sometimes used as schemes
… not clear how critical the use cases are
… may confuse users to say some IRIs cannot be anything else, but some could be compact IRIs in disguise

Ivan Herman: does this mean we should have a list of prefixes that are schemes?

Pierre-Antoine Champin: no, trying hard not to say that
… current rule is scheme://
… and this is clear cut, non-ambiguous
… it might be confusing to do this for non // schemes

Rob Sanderson: so our approach is to leave this to context authors rather than trying to maintain a universal list
… this will almost certainly come up in security horizontal review
… it would be nice to solve or improve it
… if prefix: false works, we’re done

Proposed resolution: If @prefix: false works, then we can turn 177 into a best practice. If not, then 177 becomes an issue to improve @prefix to allow it. (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

Rob Sanderson: otherwise we have to improve prefix: false so it does work

Tim Cole: +1

Adam Soroka: +1

David I. Lehn: +1

Benjamin Young: +1

David Newbury: +1

Resolution #3: If @prefix: false works, then we can turn 177 into a best practice. If not, then 177 becomes an issue to improve @prefix to allow it.

3.3. IRI expansion

Rob Sanderson: ref: https://github.com/w3c/json-ld-syntax/issues/191

Rob Sanderson: essentially, what I took away from this issue is that what is wanted is a way to set defaults per prefix
… e.g., everything with x prefix, everything is a list
… since we declare intent to close to new features (after last published draft)
… so, can we defer this?
… or is it a bug we have to address

Benjamin Young: the use of this seems to want ad hoc terms mixed in with the prefix declaration
… the first example seems that way
… seems he could get same result with slightly more verbose (less confusing) instance

Adam Soroka: this reminds me of java server tags
… not clear that this is something json-ld was supposed to do.
… this seems to be about complex structures, almost transformative
… this is not the focus of json-ld. important to do, but not really our intent here

Ivan Herman: so what I understood from the issue is that this is not a bug, but really is a new feature
… so the answer should simply be that we defer because of the feature freeze and avoid discussing the details

Adam Soroka: should we send to CG

Ivan Herman: since we are not closing issue, we don’t need to send to CG
… the person submitting may want to do so.

Proposed resolution: Defer syntax#191 and api#94 as new features after feature freeze (Rob Sanderson)

David Newbury: +1

Rob Sanderson: will do same for issue in api

Ruben Taelman: +1

Benjamin Young: +1

Rob Sanderson: +1

Tim Cole: +1

Ivan Herman: +1

Adam Soroka: +1

Pierre-Antoine Champin: +1

Resolution #4: Defer syntax#191 and api#94 as new features after feature freeze

Action #3: post blog reference for feature freeze (Rob Sanderson)

Ivan Herman: please add to issue link to blog where we declared feature freeze

Rob Sanderson: can we add mention of feature freeze in repos readme

Action #4: add feature freeze note to the syntax, api, and framing READMEs and issue template for bugs only (Benjamin Young)

Tim Cole: adjourn - next call in a week (azaroth regrets)

4. Resolutions

5. Action Items