Meeting minutes
Errata
Ege: We did talk about it yesterday
Ege: let me show the rendered version
<EgeKorkan> PR 2049 - Errata Management Update
<EgeKorkan> Rendered version HTML for errata.html (Ver 1.0)
<EgeKorkan> Rendered version HTML for errata11.html (Ver 1.1)
Ege: 1.0 does not have items, 1.1 has items
Ege: I put the link to the public mailing list in case somebody has to contact us, but the main way to provide feedback is through issues
Ege: let me also show the labels
<EgeKorkan> Errata labels
Ege: are there any objections?
<no objections>
<merged>
Registry
Ege: There is a refactoring of the document
<kaz> PR 378 - Registry Requirements Update
<EgeKorkan> https://
<kaz> View of the above commit for registry-requirements.md
Ege: Those are the small changes added today
Ege: We discussed a bit on the Bindings specification ID
… regarding how to identify a binding in the TD usage
Ege: Another point about the how to register URI schemes
Ege: we have 3 opinions from cris, lu and dape, the consensus seems to be that no IANA registration is required on the first submission, but to be a fully register binding a IANA registration is required
Kaz: This sounds reasonable and kind of similar to the w3c process for media-type registration
Ege: I think we are a bit more strict
Kaz: think we should be stricter, so this proposal sounds ok
Ege: opinions on the consensus summary?
Cristiano: I think it will work as you presented it
<luca_barbato> +1
<JKRhb> +1 from my side as well
Kaz: We can probably make a TF resolution today and we can do a WG resolution next time. Then we can bring the proposal to PLH and ask him for opinions.
<EgeKorkan> PROPOSAL: Until a custodian review, no registration is needed. A full IANA registration is required for the final and stable version of the binding. The submitter SHOULD trigger the registration at IANA. If needed, the custodian MAY trigger the IANA registration. The submitter MAY do a provisional registration to simplify the process on the IANA side.
Ege: Any objections?
<kaz> <no objections>
RESOLUTION: Until a custodian review, no registration is needed. A full IANA registration is required for the final and stable version of the binding. The submitter SHOULD trigger the registration at IANA. If needed, the custodian MAY trigger the IANA registration. The submitter MAY do a provisional registration to simplify the process on the IANA side.
Lifecycle
Ege: to simplify and make sure everybody can provide even if not able to do PR, I suggest to use a Issue Template
Luca: Do we want to keep the Registry Entries separated from the actual binding, so they are strictly a form w/out much freedom or do we want to store also the actual Binding, then a PR is a must?
Ege: We want outsiders to write bindings so we want to let them use their own process and we would just maintain the registry
Luca: As implementor rather have all the bindings written in the same way with the same template, I see that giving freedom is better for the people writing it
<kaz> RFC6838 - Media Type Specifications and Registration Procedures
Kaz: we may want to look into the IANA definition and process again
Kaz: we can borrow more ideas and make sure we can use the same terminology
Ege: We can correct the terminology and keep it in sync
Ege: In our case reviewer and custodian are the same?
Luca: We have to decide if we want that binding submission follows the W3C rules and then we can bound the document to follow our format and use our tools or if we want to allow any document and we do not put any restriction on copyright&patent claims on it and is up to implementor to find it and figure out how to use it.
<kaz> Who holds the copyright on W3C documents?
<kaz> W3C CLA
Kaz: We expect that the registry is published as a REG track, we have to follow the rules for the intellectual rights
Kaz: if we go for another path, as a community group Report, the W3C CLA would apply
… we should should record all our concerns like this and talk with PLH and ask him for clarification
Versioning
Ege: How do we want to deal with evolving the bindings over time?
Ege: So far the idea is to require a resubmission and optional signal the deprecation
Ege: We should not have version within a TD version
Ege: We may have multiple initial submission
Ege: but a single final binding
Ege: I suggest those restrictions to make implementations stay simple
Cristiano: Maybe implementors can use something different from the binding prefix to detect the binding version
Luca: Since our implementation do not have to rely on JSON-LD, the prefix in general is the only thing you can use
Cristiano: A new prefix would allow let the implementation use as a way to recognize an additional version
Ege: A bigger question is what happen if we somebody want to deprecate the binding and make one anew while keeping the prefix
Luca: We do not have anything in which we explicitly state how a binding should be parsed?
<kaz> IANA Media Types Registry
<kaz> RFC6383
Kaz: We could also look at how rfc6838 deals with deprecation and upgrading
AOB?
Ege: do we have other quick business for today?
<kaz> none
<kaz> [adjourned]